►
From YouTube: IETF101-REGEXT-20180321-1520
Description
REGEXT meeting session at IETF101
2018/03/21 1520
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
A
Yeah
so
I'm,
looking
at
the
slides,
apparently
I
left
an
extra
slide
in
there
that
we'll
just
have
to
ignore
as
we
go
along
guess
that
happens
when
you
copy
slides
from
one
meeting
to
the
next
and
you
update
them.
Sometimes
you
don't
update
them
as
perfectly
as
one
would
like.
Okay,
we
are
actually
a
couple
of
minutes
after
our
start
time.
So
this
is
the
registration
protocols,
extensions
working
group,
I'm
Jim,
gallon
and
Antoine
washer
and
who
is
remote
and
up
there
in
the
participants?
Oh
and
now
he's
waving.
A
Yes,
but
barely
it's
actually
quite
low,
that's
the
volume
in
the
room,
I,
don't
think.
That's
you
I
guess.
If
mideco
is
listening,
if
we
could
get
the
volume
in
the
room
adjusted,
that
would
be
good
if
somebody
wants
to
type
that
type.
You
know
at
neig
echo
in
the
jabber
room.
That'd
be
appreciated.
A
D
A
A
This
is
just
a
note
which
we've
always
put
in
in
our
thing.
Some
working
groups
do
this
I
know
that
other
groups
that
you
know
have
a
lot
of
documents.
You
know
like
to
just
remind
people
about
document
reviews
I
mean
we're
a
pretty
small
group
close-knit,
but
you
know
just
to
reminder
in
general,
you
know
moving
forward
and
moving
documents
forward
in
specifications.
You
know
it
really
does
help
the
people
review
documents
and
even
just
saying
a
plus-one
I
mean
if
you
don't
have
any
particular
concerns
or
issues
with
a
document.
A
It's
always
helpful
to
just
say
that
acknowledge
that
you've
looked
at
it
and
have
no
objections
when
documents
moving
forward
and
for
those
who
are
document,
editors
and
authors.
You
know
it
hopefully
goes
without
saying,
but
you
know
sure
if
you're
going
to
put
a
document
out
there,
that
you
want
people
to
look
at,
please
take
the
time
to
look
at
other
people's
documents
too.
You
can
helps.
We
have
been
having
a
little
bit
of
an
issue
with
document
Shepards.
We
kind
of
struggled
with
that
a
little
bit
here
recently.
A
We
do
have
three
documents
right
now
that
are
in
the
publication
view,
and
they
all
do
have
a
document
Shepard.
So
we
did
finally
get
to
get
past
it
all.
But
you
know,
I
do
want
to
take
an
opportunity
to
encourage
people
and
ask
please
that
you,
you
do
think
about
doing
that.
It's
not
necessarily
a
lot
of
work.
It
does
require.
A
The
principal
responsibilities
are
that
you
have
to
write
the
summary
up
that
describes
the
document
if
you've
ever
seen,
ISG
announcements
that
explain
that
a
document
is
now
an
IETF
last
call
and
it's
on
its
agenda
I
mean
you
have
to
write
those
words
that
summary
page
that
goes
there.
The
other
thing
that
you
have
to
do
is
when
the
document
is
first
submitted
to
the
IETF
to
the
isg.
A
Isg
does
its
review,
and
this
is
all
tracked
and
it's
it's
all
online
in
the
data
tracker,
but
as
they
make
comments
and
if
they
have
questions
and
concerns,
you
know
we
do
look
to
the
document
Shepherd's
to
track
all
of
that
and
respond
to
all
of
that
and
make
sure
to,
and
on
the
one
hand
your
job
is
to
keep
the
editor
of
the
document
honest.
You
know
you
have
to
make
sure
that
all
of
the
comments
and
such
are
addressed
and
all
those
concerns
are
taken
care
of.
A
A
This
is
the
version
of
the
two
meeting
side
that
we're
not
having
I
should
have
deleted
this
one.
This
is
the
one
the
next
slide
slide.
Five
is
really
the
two
meeting
slide
that
should
be
there.
We
obviously
had
a
session
already
on.
Monday
was
a
working
session.
We'll
have
a
few
minutes
here
in
a
bit
to
hear
about
that,
and
then
this
is
the
second
group
second
session
working
group
session
and
I'm.
A
Sorry,
oh
no
actually
comes
up
now,
I
just
I
just
remembered,
but
it's
also
because
we've
got
to
get
all
the
way
to
the
agenda
here,
we're
in
the
middle
of
welcome
and
introductions,
but
I
do
need
a
jabber
scribe
and
a
note-taker
anybody
in
particular
willing
to
take
notes
and
make
sure
that
we
get
them
can
I.
Look
to
our
our
usual
suspect
is
not
in
the
room
or
am
I
missing
him.
Oh
you'll
do
knows,
for
us
I'm,
sorry,
yes,
yeah!
Thank
you!
A
A
Okay,
so
with
that
we'll
jump
right
in
here
document
status,
we
had
a
document
published
since
our
last
meeting
yay
for
us
uh-huh
yeah,
it's
a
kind
of
a
very,
very
dramatic
step
for
us,
we're
kind
of
slow
moving
here
on
many
things
so,
but
it
was
good
to
get
this
one,
finally
out
the
door
and
done
so.
That
was
a
good
thing.
They
were
labeled
here
as
working
group
last
call
documents,
but
these
are
the
three
documents
the
next
set
up
here
are
all
the
documents
that
are
currently
in
the
publication
queue.
A
A
Okay,
so
Patrick's
not
with
us
here
today,
but
that's
or
is
easy
online
I
don't
see
him
online,
but
that's
okay.
Does
anybody
want
to
say
anything
about
the
documents
that
are
in
the
publication
queue?
Anybody
have
any
words
updates
that
you
want
to
offer
what
the
experience
has
been
like
so
far,
so
Jim
go
ahead.
E
F
A
A
They're
all
actually
document
shepherds
are
in
progress
doing
their
part
to
prepare
the
write-ups.
They
have
not
actually
I.
Take
it
back.
I
made
a
misstatement
before
because
they
have
not
actually
been
submitted
to
the
iesg.
Yet
they
were
waiting
for
the
document
shepherds
to
to
finish
their
write-ups
and
they're,
just
some
knits
that
they
were
going
through
with
the
editors
and
actually
I.
Think
the
change
in
allocation
are
waiting
on
the
chairs
to
look
at
your
first
write-ups
I.
A
F
I
didn't
have
much
to
say
on
this,
except
that
there
hasn't
been
a
lot
of
comments
on
it,
but
we
do
have
implementation
going
in
in
the
next
month
or
so
so.
I
will
be
updating
a
doc
with
the
implementation
notes
and
any
findings
that
we
actually
have
so
it'll
be
prior
to
the
next
meeting
and
I'm
hoping
to
actually
by
June
ish
that
we
actually
have
enough
day
doc
and
a
full
implementation
done
on
it.
So
for
the
nets
for
the
validate
document.
So
any
questions
on
validate.
D
F
H
F
H
D
F
No
okay
registry
mapping:
we
did
meet
Monday
to
work
on
this
overview.
Probably
half
the
time
we
just
went
over
what
the
concept
was
and
everything
and
the
questions
started
out
a
little
slow,
but
it
actually
picked
up
quite
quickly
and
some
good
conversations,
probably
the
two
biggest
things
and
I've
actually
heard
something
since
then
as
well,
is
the
the
bootstrapping
of
it
is
I.
Think
Kel
mentioned
Tom
Monday
was:
how
can
we
get
this
out?
F
J
Got
the
Scott
Hollenbeck
interesting
that
you
asked
that
question:
Mario,
Andy,
Newton
and
I
had
been
having
a
little
private
conversation
amongst
ourselves,
because
Mario
has
suggested
that
maybe
this
information
could
also
be
published
using
our
DAP
now.
Having
said
that,
I
think
we
do
have
to
take
a
look
at
the
issues
of
that
might
be
associated
with
client,
identification,
authentication
and
access
control.
Though
you
also
just
said
about
the
general
public
anyway,
I
think
it's
a
good
topic
for
conversation.
J
F
Scott
on
that
same
point,
actually
is
the
next
other
topic
to
start
thinking
about
is:
is
this
public
information
and
should
it
be
available
to
public
Ora's
are
gonna,
be
pieces
that
are
private
and
I'm,
not
sure
that
we
know
that
today,
but
I
think
it's
just
something
we
need
to
think
about
as
we're
going
through
and
designing
it.
If
we're
going
to
add
private
information,
then
we're
going
to
have
to
come
up
with
some
other
mechanism
of
supporting
it
to
bootstrap
or
to
bribe
to
the
public.
So
Jim.
E
Yes,
Jim
we're
going
from
Verisign,
so
I
think
fundamentally
giving
the
policies
and
a
structured
format
is
number
one
it
could
be
in
EPP.
It
could
be
an
art
app.
It
could
be
at
anything
you
want.
So
the
point
is:
is
that
I
think
I'm
in
agreement
with
what
those
policies,
how
that
can
be
represented
and
you
could
represent
them
in
any
way,
shape
or
form?
You
could
put
it
in
a
Word
document
HTML.
J
Scott
Hollenbeck
again,
but
let
me
build
on
that
for
a
minute
Jim.
If
you
want
to
go
with
some
kind
of
a
structured
format,
what
I
would
strongly
suggest
is
that
we
decide
on
one
write,
because
as
soon
as
you
get
information
that
is
represented
in
two
different
ways
or,
for
example,
if
there
are
two
copies
of
this,
you
know
that
might
exist
in
different
places.
The
risks
associated
with
maintaining
consistency
increased
greatly
right,
yeah.
E
Well,
my
suggestion
is
to
stick
with
EPP
for
right
now.
Maybe
what
we
can
do
is
come
up
with
a.
We
talked
about
an
aggregation
pattern.
In
essence,
you
may
have
individual
registry
systems
each
exposing
their
policies
via
the
EPP,
but
then,
if
we
have
aggregation
services,
whether
or
not
have
the
registry
provider
level
or
the
ICANN
level,
that
can
be
represented
in
a
different
format
and
that's
all
I'm
saying
yeah.
F
G
Case
just
on
that
and
I
know,
I
raised
this
on
Monday
I
think
that
logically,
some
of
this
material
that
the
bootstrap
material,
that
I
was
thinking
of,
was
just
just
the
bare
minimum
required
to
connect
to
the
server
in
the
first
place,
to
get
potentially
more
rich
policy
data
later.
But
when
you
imagine
and
referring
to
the
requirement
that
we
would
store
this
data
potentially
in
the
same
in
two
locations
or
more,
but
it
would
have
to
be
consistent.
Some
of
this
will
have
a
different
level
of
secrecy.
G
Basically,
so
there
may
still
be
a
necessity
to
make
some
of
a
public,
or
at
least
more
public
than
perhaps
a
direct
connection
to
an
EPP
system
might
require,
and
the
rest
would
still
remain
confidential
effectively.
So
we
might
need
to
think
about
that
that
it
may
not
exist
in
a
complete
document
when,
when
it's
distributed,
yeah.
F
K
Food
electronic
thought
we
are
I,
I
guess
if
we
are
thinking
the
major
use
case,
the
bootstrapping
one.
It
really
doesn't
make
too
much
sense
to
put
this
in
in
the
EPP
server.
Actually,
the
the
formatter
I
don't
mind,
being
XML
or
or
whatever,
but
I
I
don't
see
too
much
Valerie
for
us
to
spend
time
here.
Writing
a
extensive
or
a
large
extension
just
for
something
that
will
be
used
in
a
pre
EPP
situation.
So
I
I
totally
agree
with
this
a
single
format.
I
I
think
regarding
this
question
of
public
or
private
information.
K
This
depends
on
the
situation
and
the
agreement
that
you
have
with
the
the
pre
agreement
that
you
have
with
this
and
you
registrar,
but
I
I
think
it's
valuable
work,
but
I
don't
see
too
much
value
in
in
putting
this
in
actually
in
the
protocol
itself
and
I
see.
This
is
probably
from
the
point
of
view
of
a
server
operator
like
us
and
in
others,
it's
straightforward
to
do
that,
but
I
don't
see
too
much
value
for
especially
midsize
to
small.
K
F
And
I
I
think
that's
a
great
conversation
that
we
can
have,
because
it
is
one
of
those
things
where
the
initial
use
of
it
would
be
but
way
prior
to
any
systems
connecting
so
yeah.
That
makes
sense.
The
only
issue
is
you're
right
and
I.
I've
talked
to
several
registrar's
and
even
if
they
do
have
some
configuration
out
of
it
coming
from
it,
they're
not
looking
at
a
lot
of
it
being
Auto
configure
that
GoDaddy
yeah
we
we
would
look
at
80%
or
above
to
auto
configure,
because
our
systems
are
completely
data-driven
themself.
F
A
So
Jim
Galvin
speaking
for
myself
here,
just
to
build
on
what
frederico
saying,
I
think
that
a
distinction
to
make
another
use
case,
which
we
have
in
mind-
is
the
transfer
of
TLDs
from
one
one
service
provider
to
another.
So
there's
a
there's,
a
use
case
down
the
road.
You
can
also
imagine
a
use
case
of
what
happens
just
if
an
operator
wants
to
make
changes.
You
know
to
their
their
operating
details
and
the
way
that
stuff
works.
So
a
point
of
discussion
here
is
all
of
that.
A
But
another
one
also
factors
in
as
a
point
of
discussion
is
maybe
there's
a
maybe
there's
a
separation
here.
Maybe
part
of
this
document
is
just
operational
details
and
not
the
rest
of
the
policy
stuff,
and
that
might
be
a
split
that
we
should
think
about
and
the
way
in
which
we
should
do
it,
because
it's
that
operational
stuff
would
be
more
applicable
in
in
use
cases
down.
The
road
outside
of
bootstrapping.
E
Yeah
human
goal
from
Verisign,
so
you
know
I,
wouldn't
give
up
completely
on
the
configuration
it's
one
point
out.
None
of
the
registries,
except
for
Verisign,
has
this
kind
of
feature
at
this
point
and
registrar's:
don't
have
an
opportunity
to
do
this
and
the
fact
matter
is
that,
as
far
as
having
it
be
centrally
defined
in
the
system
or
have
it
be
aggregated
for
me,
source
code
is
is
best
followed
by
going
directly
to
the
source
code.
For
me,
personally,
I
don't
want
to
go
to
a
word
document.
That's
out
of
date.
E
E
K
Have
too
much
it's
written
again
from
NIC,
but
yeah
I
don't
have
too
much
to
aggregate
III
agree
with
that,
but
anyway,
I
I
think
we
should
I
would
like
better
for
us
to
spend
a
little
bit
more
time
in
trying
to
improve
the
protocol.
From
the
point
of
view
of
the
use
of
the
basic
protocol
that
we
have.
The
this
comment
is
because
it's
a
little
bit
sad
from
a
point
of
view
of
a
server
operator,
the
way
that
a
small
registrar
street.the
the
protocol.
K
That
date
we
it's
very
usual
for
us
to
receive
calls
from
registrar's
asking
to
please
clean
my
500,000
pool
message
that
I
have
not
be
treating
for
the
last
two
years
and
then
receiving
support
calls
that
oh,
this
is
not
working.
It's
obviously
you
are
not
reading
the
the
poll
messages.
That's
it
says
Paul
impossible
to
work
that
way,
so
I
don't
know
what
we
could
do
to
try
to
improve
this
situation
and
I.
F
F
A
So
there's
actually
two
things
in
the
next
step,
just
Calvin's
being
his
chair,
so
you
have,
you
do
have
to
make
an
internet
draft
out
of
it
and
we
have
to
agree
as
a
working
group
to
actually
adopt
this
as
a
work
item,
and
we
can
have
a
bit
of
that
discussion
when
we're
doing
our
milestone
review
in
a
bit.
So
a
thing
but
I
mean
worst
case.
A
You
create
an
internet
draft
and
then
we
just
do
a
call
for
adoption
on
the
mailing
list,
and
you
know,
let
me
just
submit
it
as
an
individual
and
then
we'll
or
maybe
since
I
I.
Don't
imagine
anyone's
gonna
object,
we'll
just
let
the
first
one
come
through
as
a
being
named
as
a
working
group
document,
but
we'll
do
a
call
for
adoption
once
the
first
draft
is
out
there
and
people
can
say
it
just
to
save
that
step
of
having
to
publish
it
twice.
It
seems
like
a
little
bit
of
overkill.
A
A
However,
what
I'm
going
to
do
here
is
move
to
showing
in
the
media-
oh
I'm,
actually
just
gonna
go
to
the
website
to
show
the
stuff,
that's
there,
so
for
people
who
can
be
on
the
website,
you
might
want
to
just
go.
Do
this.
This
is
the
first
link
the
about
link,
it's
about
our
working
group
and
down
here
at
the
bottom.
So
you
see
our
charter
and
if
you
scroll
through,
you
can
see
our
milestones
listed,
which
I
think
all
fit
on
the
display
in
one
slot,
so
that's
actually
pretty
cool.
A
So,
let's
just
do
a
couple
of
quick
words
here
on
where
I
know
we
are
actually
Antoine
was
gonna,
try
and
and
walk
through
this
I'm
just
having
I
apologize
that
I'm
coughing
I've
got
a
little
bit
of
a
chest
cold
which
is
coming
on
me
here
Antoine.
You
want
to
try
and
talk
again,
and
maybe
you
can
can
walk
through
this.
Otherwise
I'll
just
keep
moving
us
along
and
I
can
see
your
lips
moving,
but
there's
no
sound
coming
out.
Yeah
all
right,
I
think
we're
gonna
have
to
pass
okay.
A
A
The
obvious
things
that
do
have
to
change
of
course
is,
as
you
can
see
at
the
bottom,
the
one
dot
can't
know
the
launch
phase
document
will
have
to
be
changed
to
published,
so
we
haven't
done
any
recent
updates
either.
So
we'll
take
care
of
that.
The
fees
document
and
the
change
poll
and
the
allocation
token
will
all
be
changed.
To
reflected
they're
going
to
be
published
soon
so
will
will
update
those
dates
so
that
it
just
reflects
that
they're
going
to
be
done
now
as
part
of
doing
all
of
us.
A
A
A
A
So
those
are
the
org
dress.
We'll
come
back
around
to
those
then
going
me
up.
We
have
the
dns
operator
our
our
protocol
document.
Let
me
the
the
question
is
what
we're
actually
going
to
do
with
that
document
and
where
we
want
to
go
with
it.
The
editor
of
that
document,
those
guys,
have
kind
of
fallen
off
the
map
here
at
the
moment,
so
they
haven't
been
pressing
to
move
this
document
along.
So
I,
don't
really
know
what
to
say
about
it.
It's
it's
targeted
for
informational
document,
but
it
has
kind
of
left.
A
Our
our
radar
here
I
know
that
the
editor
who
had
pen
was
had
some
some
personal
issues
for
a
while,
but
I
thought
that
he
was
back
at
work.
So
we
actually
don't
know
what
to
do
about
that
document.
For
the
moment,
I
think
that
if
we
can't
make
contact
with
one
of
the
editors
and
if
anyone
here
has
a
point
of
view
about
that
document
and
wants
to
move
it
along,
it
would
be
helpful
if
you
could.
A
A
A
That
leaves
us
the
bundling
document
up
at
the
top,
and
you
know
Adam.
This
is
a
question
in
part
to
you
on
the
bundling
document.
It
was
originally
targeted
for
standard
track
and
we
had
the
buff
about
it,
I
guess
about
a
year
or
so
ago
about
having
a
bun
wing
Bop
instead
and
under
the
idea
that
this
document
might
move
in
that
direction.
A
We
just
kind
of
left
it
here
part,
but
now
the
question
is
whether
or
not
if
we
could
move
that
to
informational
instead
and
and
have
it
pushed
out
the
door
that
way,
and
if
you
want
to
speak
about
that
right
now,
you
can
or
if
you
want
to
take
a
few
minutes
and
think
about
it.
I'll
just
put
that
question
out
there
for
the
moment.
A
Okay,
so
some
thoughts
about
that.
Now
so
that
takes
care
of
the
items
on
here.
So
the
questions
to
the
group
here
we'll
come
back
to
talking
about
org,
but
the
question
is
updating
these
things
to
have
sensible
dates
and
milestones
so
I
think
that
leaves
the
validate
out.
We
should
consider
whether
or
not
the
May
of
2018
is
is
a
reasonable
milestone
for
that
and
getting
it
done.
A
If
we
want
to
extend
that
and
push
it
out
a
bit,
that's
fine
and
I
think
everything
else
is
on
track
and
under
control
here,
we'll
talk
about
Oregon
a
minute.
So
let's
talk
about
other
documents
that
we
have
that
are
not
here.
We
also
have
Scott's
tagged
document,
which
is
not
currently
listed,
which
has
to
be
added
to
the
list.
So
we
need
to
talk
about
a
date
and
a
timeline
for
that
see.
If
anyone
has
any
suggestions
or
preferences
on
how
they
want
to
do
that
and.
A
A
J
A
road
so
here's
what
I'm
thinking
with
the
object
tagging
document
I
know,
Andy
and
I
have
tried,
prompting
some
conversation
on
lists.
You
know
more
than
once
we
did
have
some
feedback
from
Patrick,
which
was
along
the
lines
I,
don't
like
the
entire
approach,
but
we
didn't
like
his
approach
either.
So,
what's
in
the
document
is
going
to
stay
there.
J
A
A
So
I
think
you
know,
even
for
that
document,
I
mean
I,
agree
with
Scott.
You
know,
as
in
terms
of
a
process.
If
there's
no
comments
to
add
to
the
review,
then
it
can
move
along
fairly
smartly.
Here,
there's
no
reason
to
hold
it
back.
I
mean
he
can
make
the
change.
That's
there.
We
are
going
to
have
to
do
a
working
group
last
call
and
would
very
much
going
to
need
opinions
and
comments
and
advice
from
others.
Even
if
it's
just
I
support
this
document.
A
A
And
Adam
has
kind
of
get
a
reflex
reaction,
I
mean
I,
wasn't
I.
Wasn't
we
can
sort
this
out
later,
I
I
had
always
thought
you
put
everything
on
the
milestone
list
and
you're
nodding
your
head.
Yes
to
that,
Antoine
was
suggesting
there
that
we
only
put
standard
track
documents
in
the
milestone
list,
but
I
don't
know
that
that
distinction
is
too
important.
Do
you,
okay,
so
Adam
said
anything
we
plan
to
publish
is
on
the
milestone
list,
so
it
should
go
there
for
tracking,
so
we'll
just
that's
the
way
that
will
we'll
do
that.
A
Okay,
so
that
takes
care
of
the
object
tag
Oh.
What
I
want
to
say
is
this
is
a
small
group
and
there
really
aren't
that
many
of
us
in
general
I,
you
know
as
chairs,
Antoine
and
I
have
always
looked
essentially
for
unanimity.
You
know
that
or
for
there
to
be
essentially
no
objections
to
a
document
and
it
is
kind
of
hard
generally.
That's
worked
for
us
because
we're
such
a
small
group,
just
asking
for
you
know
all
of
us
to
be
part
of
something
seems
to
seems
to
work.
A
Fine
and
we've
had
pretty
good
success,
but
since
we
have
a
document
here
which
has
an
objection,
it's
much
more
important
to
make
sure
that
people
acknowledge
that
they
want
a
document
and
they
have
no
objections
to
it.
I
need
to
give
you
know
if
Patrick
has
an
objection,
he
needs
the
opportunity
to
state
that,
but
as
chairs
we
need,
we
need
for
other
people
to
comment
on
whether
they
support
the
document
or
not.
In
order
to
get
past
that
Scott
Scott.
J
Hollenback,
if
I
could,
if
I
number
of
channeling
Patrick
here
I,
think
that
we
ultimately
got
him
to
admit
that
this
was
more
a
case
of
he
would
hold
his
nose
as
opposed
to
I
object.
Strongly
I
mean
this
was
on
list
on
memory,
remembering
this
incorrectly
folks,
please
just
you
know
correct
me,
but
I
think
that's
where
we
ended
up.
Okay,.
A
Good,
that's
good
to
know
thanks
for
that
clarification,
so
my
reminder
to
people
to
at
least
acknowledge
that
you
have
no
objection
to
a
document
is
important.
Whenever
there
is
an
objection,
since
we
don't
get
that
many
of
them
in
the
screw,
we
generally
seem
to
have
unanimous
support
for
things
and
that's
a
that's
a
good
thing.
A
A
The
reason
why
I
ask
is
the
milestone
list
puts
it
at
January
of
2018,
which
was
obviously
a
couple
of
months
ago,
and
it's
okay.
We
just
need
to
push
that
milestone
date
out
to
some
through
July,
okay,
why
don't
I
just
make
it
July
to
push
it
to
the
next
ITF
meeting?
Thank
you,
okay,
so
that
takes
care
of
that
document.
So
that's
that
one
that's
object.
Tag
validate!
F
A
A
J
Scot
Hollenbeck
so
I
know
I've
talked
about
this
one
here
in
the
past.
I
am
currently
working
on
an
individual
submission
for
our
deaf
that
describes
how
federated
authentication,
you
know
can
be
used.
You
know
for
client,
identification
and
authorization.
I
haven't
yet
brought
this
to
the
group
for
consideration,
because
it
still
has
what
I
consider
to
be
a
significant
hack
in
it.
That
describes
how
this
would
work
with
command-line
clients
like
curl
and
W
get.
J
However,
that
situation
has
changed
in
the
last
few
months,
because
the
OAuth
working
group
is
pushing
something
that
they
call
the
device
flow.
It's
very
much
intended
to
describe
a
method,
for
you
know
doing
off,
based
authorizations
for
devices
that
are
UI
constrained
and
we're
talking
about
a
command-line
interface,
so
it
doesn't
get
more
constrained
than
that.
So
I've
got
my
implementation
team
back
home.
You
know
working
on
trying
to
work
the
device
flow
into
our
existing
implementation
and
once
they
demonstrate
how
it
can
be
implemented.
J
J
All
right
and-
and
one
other
thing
to
consider
here,
even
though
this
is
our
gap
specific
for
those
of
you
who
aren't
following
along
and
I,
can
space
with
what's
going
along
with
who
is
and
the
GD
for
general
data
protection
regulation.
You
know,
I
can
is
currently
modeling
over
a
number
of
proposals
for
dealing
with
tiered
authentication
in
Whois
I'm
really
worried
that
they
are
going
to
adopt
something
for
who
is
that
is
somehow
going
to
live
far
beyond
its
usefulness
and
somewhat
taint
what
we
can
and
cannot
do
with
our
DAP
going
forward.
J
A
E
Yes,
Jim
Gould
I
wanted
to
speak
to
the
verification
code.
Draft
I'm
gonna,
just
a
request
that
that
stay
on
hold
I,
don't
know
exactly
sure
what
that
means.
But
since
we're
the
only
ones
implementing
we'd
have
to
decide
like
what
we're
gonna
do
with
it
and
whether
or
not
there
are
other
places
where
it
may
be
used.
But
right
now
I
think
it's
a
generic
solution.
That's
worthwhile
proceeding!
If
there
is
interest
from
other
registries
to
do
so,
but
right
now
I,
don't
see
that
happening.
E
There
are
other
data
escrow.
The
data
format
drafts
that
I've
talked
to
and
prior
working
groups
that
I'm
not
sure
whether
or
not
there
was
an
open
question
whether
or
not
it
could.
Those
could
be
taken
on
based
on
the
Charter,
but
if
they
are,
then
data
escrow
and
the
data
set
format
drafts
would
be
requested,
be
added
right.
A
And
actually
I'll
extend
that
list
a
bit
more
in
a
moment
where
I
think
we
are
so
we
have
the
object,
tag
and
validate
drafts
which
will
move
along
smartly.
Here,
as
soon
as
we
get
another
published
draft,
we
have
the
DNS
operator
draft,
which
we
will
push
out
to
July
and
the
verification
code.
You
didn't
actually
give
me
a
date
when
do
you
want
to
push
a
milestone
out
for
that?
If
you
have
a
suggestion
for
it,
I.
E
A
B
And
then,
after
a
period
of
working
group
discussion,
we
chose
to
change
the
reseller
object
to
the
organization,
object,
object
and
I
think
we
have
done
this
work
last
year
and
then
we
did
receive
some
comments
on
mailing
lists
for
the
organization
dropsy,
and
we
have
responded
all
the
comments
and
and
some
wording
and
the
examples
were
updated
in
the
latest.
The
new
version
and
and
the
courses
have
been
discussed
Wow
and
we
thought
that
it
might
be
proper
time
for
us
to
request
a
working
group
last
call
and
to
push
them
forward.
B
A
A
M
M
To
that
question
right:
well,
that's
not
a
formal
barrier
for
putting
things
into
the
first
step
of
standards
track
right,
that's
that's
necessary
for
subsequent
progression,
but
I.
Don't
think
that's
what
you
want
to
gate
these
things
on
the
other
thing
that
I'm
going
to
raise
is
kind
of
a
flag
is,
while
the
conversation
hasn't
been
had
I
know.
One
of
the
things
that
we
plan
to
talk
about
at
the
upcoming
iesg
retreat
is
the
publication
of
informational
documents
that
look
like
standards
and
as
I'm
looking
through
those
they
contain
protocols,
extensions
to
standard
protocols.
M
So
if
you
do
decide
to
make
them
informational
there,
there
might,
depending
upon
the
outcome
of
that
conversation,
be
some
pushback
when
it
comes
time
to
publish
them.
So
if
there's
kind
of
a
just
on
the
bubble
about
whether
there's
you
know
want
informational
versus
standards
unless
there's
a
pretty
strong
reason
to
put
them
informational,
they
look
like
protocols.
I
kind
of
you
know
recommend
putting
them
in
the
standards
bucket.
M
A
That's
that's.
That's
helpful,
that's
good
to
know-
and
that's
kind
of
been
an
issue
for
us
here
and
talking
about
things
I
admit
even
for
myself,
I've,
always
kind
of
fallen
back
on
the
idea
that
you
should
have
multiple
implementations
to
be
on
the
standards
track,
because
I
was
about
to
push
back
on
Jim
on
on
the
verification
code
document,
if
they're
the
only
ones
that
did
it
should
it
be
standards
track
right.
M
I
mean
he
planned
to
progress
them.
Then
you
won't
do
that
before
you
putting
put
them
further
down
the
path,
but
first
step
single
elimination.
That's
fine!
So
you
can
be
proposed
to
ended
with
the
one
implementation.
So
that's
fine
right!
Okay,
I,
don't
know!
If
that
impacts
the
you
had
a
question
about
the
the
bundling
draft,
which
I
think
was
predominantly
into
whether
it
was
informational
versus
standards
and
I.
Think
probably
I
would
offer
the
same
guidance
in
that
yeah.
A
The
bundling
graph
had
the
bundling
draft
has
a
has
a
different
issue.
If
you
recall
from
the
bot
that
we
had,
it
was
more
about
whether
or
not
the
DNS
community
won
in
such
a
thing
even
exists
as
a
as
an
Internet
standard.
As
a
proposed
standard,
there
was
a
lot
of
pushback
in
trying
to
create
a
a
bundling
ball
that
would
allow
us
to
explore
this
issue.
Okay,
I,
don't
remember
the
bluff
itself
was.
This
was.
A
A
M
A
You
know
my
recollection
just
as
chair
is
that
you
know
that
particular
document
additional
constraints
or
issues
that
we're
coming
to
bear
on
it.
They
that
document
was
would
like
to
be
a
standards
track.
Just
like
these
org
documents,
which
I
think
now,
based
on
what
you
just
said,
we
can
move
that
forward
and
verification.
A
M
A
A
What
I've
heard
here
in
in
in
both
cases
for
verification
code
and
for
the
the
two
org
drafts
go
away
and
the
org
drafts
are:
are
these
two
here?
Is
you
know
unless
there
is?
Unless
there
is
an
objection,
and
it's
a
you
know,
a
technical,
substantive
objection
that
those
two
documents
are
also
ready
for.
A
A
You
know,
let's
not
forget
the
the
Ayana
registry
for
registering
extensions,
so
even
if
they're
informational,
they
get
to
be
put
there.
But
you
know
these
are
going
to
be
standards
tracks,
so
we
should
add
them
there
too,
and
those
should
come
along.
So
we'll
do
a
working
group
last
call
on
those
on
those
documents.
So
back
again
in
summary,
I
think
that
leaves
us
with
the
DNS
operator
document
I,
think
that's,
oh
and
and
the
bundling,
which
will
have
to
follow
up
and
and
address
offline
as
to
where
to
go.
A
Scott
offered
up
a
couple
of
documents
that
had
come
down.
The
pike
and
I
do
want
to
offer
up
the
following
two:
we
don't
have
a
large
number
of
registrar's
that
participate
in
this
working
group
and
participate
here
directly.
Now,
we've
talked
about
this
issue
before,
and
so
this
is
just
partly
a
recollection
for
folks
to
bring
it
forward
again
so
that
you're
aware
of
it.
There
are,
on
the
other
hand,
a
great
larger
number
of
registrar's
that
participates
in
in
the
ICANN
arena.
A
The
the
thing
that
I
want
to
bring
out
is
there
are
a
number
of
specifications,
technical
specifications
for
operational
concerns
that
are
coming
from
that
registrar
community,
that
they
are
since
they
now
have
a
vibrant
tech
operations
group.
Those
things
are
under
discussion
and
they're
developing
those
documents.
The
intent
is
that
since
that's
the
place
where
that
group
is
working
to,
let
them
do
that
work
there,
and
then
we
will
submit
it
here
and
bring
it
here
to
give
it
to
the
IETF
for
IETF
control.
You
know
for
broader
review
and
then
ultimate
publication.
A
A
So
there
are
a
number
of
documents
which
are
on
the
list
that
are
going
to
come
our
way
fairly
soon.
We
actually
do
have
I
think
there's
one
down
here
already,
which
we
have
not
adopted
and
I
actually
don't
have
it
on
my
list.
So
it's
gotten
lost
here,
but
there
is
an
unavailable
names
document
which
has
actually
been
through
the
it
is.
An
internet
draft
will
resurrect
that
one.
There
is
some
discussion
about
creating
standards
for
file
names
for
reports
that
are
generated
between
registries
and
registrar's.
A
So
there
is
a
there
is
an
an
existing
document
for
that
also-
and
there
is
some
discussion
going
on
now
about
a
billing
transaction
format,
file
a
file
for
formatting
billing
transactions,
which
the
registrar's
would
like,
and
it's
just
a
way
for
them
to
reconcile
their
invoices.
Those
are
the
three
things
that
come
to
top
of
mind
at
the
moment,
just
to
alert
you
to
work
which
is
coming
our
way,
but
Jim
go
ahead.
Please
yeah.
E
A
Able
to
take
on
that
work,
yep
I'll
speak
to
that
very
quickly.
I
have
actually
already
talked
to
our
area
director,
and
you
know,
since
these
things
are
all
in
the
context
of
registration
work.
Yes
I,
you
know
your.
Your
chairs
will
acknowledge
that
they
have
been
negligent
doing
this.
We
had
actually
agreed
to
it
before
and
I
had
at
this
meeting.
I
raised
it
again
with
Adam.
A
Here
we
we
do
have
the
ability
to
just
tweak
our
charter
a
little
bit,
there's
just
a
couple
of
phrases
to
change,
because
we
don't
want
to
change
the
overall
scope,
but
we
want
to
lift
the
restriction
from
being
EPP
and
our
DAP
only
to
being
registration
protocols
with
EPP
and
our
DAP
is
cus.
Keep
us
in
scope
here.
So
to
the
extent
that
these
things
are,
you
know
just
for
registration
systems.
We
should
be
okay
and
we
do
have
to
get
that
charter
updated
and
make
that
happen
before
we
can
actually
adopt
these
documents.
A
N
May
over
I
understand
that
participation
of
registrar's
in
that
group
is
pretty
limited
and
even
write.
Participation
of
registries
is
well
not
the
whole
industry.
However
I'm
slightly
worried
by
the
fact
that
there
is
some
specification
work
going
on
in
a
gated
community,
which
is
then
supposed
to
be
rubber-stamp
by
the
ITF
to
become
an
RC
yeah.
So
without
like
paying
the
registry
stakeholder
group,
membership
fees
and
being
an
accredited
I
can't
really
read
history.
N
N
A
Let
me
speak
to
that
directly
to
very
sensitive
I
agree
with
your
sensitivity
to
that
issue
and
want
to
acknowledge
that
I'm
very
sensitive
to
a2,
as
are
others
and
we've,
had
this
discussion
and
a
and
you
know
then
I
yeah
and
the
intent
here
is
absolutely
not
to
take
over
the
ietf
process.
Okay,
that
is
that
is
not
the
intent.
A
I
know
that
people
will
be
quick
to
say
that
you
know
they
could
just
join
our
mailing
list
and
they
can
participate
here
and
do
that
and
and
I
really
do
appreciate
that
and
for
people
who
are
part
of
the
IETF.
We
get
that
that's
how
things
work.
The
truth
is
we're
just
not
getting
them
to
do
that
and
they're
not
interested
in
doing
that
registrar's
in
general,
and
that's
kind
of
unfortunate.
A
We're
taking
advantage
of
the
fact
that
there
is
a
a
group
of
technical
people
who
are
willing
to
work
on
something
and
we're
just
using
that
opportunity
to
get
a
you
know
can
think
of
it
more
as
a
design
team
than
a
closed
community
doing
something,
and
they
fully
acknowledge
and
recognize
that
no,
the
change
control
comes
to
the
ITF
it's
coming
over
here
and
it
is
subject
to
IETF
review
and
consensus
and
change
control
and
that's
what
it
is.
It's
it's
definitely
not
a
rubber
stamp.
A
N
Frankly,
I'm
not
sure
whether
the
ITF
process
is
the
right
venue
for
some
of
those
documents,
I
believe,
for
example,
that
the
format
of
a
billing
line
of
a
registry-
this
is
purely
an
inter
industrial.
It's
not
a
protocol
yeah,
so
if
they
want
an
RAC
number,
they
can
like
invent
something
else
that,
as
an
acronym
forms,
RFC
yeah,
but
it
seems
like
they
want
to
crown
some
of
the
documents
with
an
RC
number
yeah,
and
but
they
don't
want
us
to
be
involved
in
the
development
of
that.
So
I'll
speak
partly
to
that.
A
N
A
J
Hall
in
back
actually
thank
you
for
teeing
this
up,
because
they're
things
I
want
to
mention
about
this
too
right.
Indeed,
the
process
here
is
not
want
to
throw
that
an
internet
draft
over
the
fence-
and
you
know,
Bango
it
pops
out
as
an
RFC
and
directly
to
that
point.
I
would
oppose
adoption
of
any
internet
draft
unless
there
is
an
active
document
author
that
is
working
over
here
in
this
community.
J
You
know
that
is
willing
to
engage
with
this
working
group
to
deal
with
the
discussion,
the
edits
and
the
kinds
of
things
that
have
to
happen
to
be
part
of
our
normal
document
development
process.
Right
so
everything
everybody
just
said
here,
but
if
the
idea
is
to
publish
a
proposed
standard
using
the
ITF
process,
we
have
to
follow
the
process.
You
know
go
from
A
to
Z,
not
said.
F
A
Yeah
and
so
Jim
Calvin
speaking
for
my
myself
here
as
a
from
the
center
microphone
I
I'm,
actually
in
in
favor
of
some
of
these
things,
although
I
take
your
point
that
they're
they're
not
really
necessarily
IETF
standards
in
a
traditional
protocol
kind
of
sense,
you
know,
but
certainly
the
ITF
has
standardized
other
things
that
are
not
necessarily
protocols.
I
mean
you
know,
API
is
kind
of
thing.
For
example,
for
me
as
a
speaking
as
a
registry,
these
things
had
to
fall
into
a
category
of
they
do
affect
operations.
A
You
know,
I
mean
it
is
a
technical
kind
of
specification
and
there
is
a
value
and
I
think
some
significant
value,
maybe
more
so
on
the
registrar
side
than
the
registry
side
to
have
a
uniform
way
to
do
this.
You
know
because
it
is
important
information
and
it
does
affect
the
overall
operation
of
the
system,
so
I
mean
I'm
generally
supportive
of
moving
these
documents
forward
and
having
them
here,
because
the
other
question
I
would
ask
is,
if
not
here
then,
where
you
know
the
IETF
in
in
some
cases,
I
mean.
A
Maybe
you
have
to
to
relax
the
lines?
A
little
bit
for
what's
reasonable
to
be
in
the
IETF,
you
know
publication
path,
so
we
get
to
think
about
that
with
each
of
these
documents,
but
on
the
other
hand,
I,
don't
know
where
else
I
would
put
a
public
repository
of
a
technical
specification
of
this
type.
That's
all
so
and
I
see
our
area
directors
coming
up
with
some
thoughts,
but
go
ahead.
Please.
N
Alex
may
offer
nobody
prevents
the
CPH
tech,
ops,
group
or
whatever
of
those
groups
to
create
their
own
document
series.
That's
that's
a
recommendation
for
the
format
of
billing
lines.
Yeah
fair
enough.
Why
does
it
need
an
RC
number
do?
Thus,
the
format
of
travel
agencies,
exchanging
bookings
with
Airlines
require
an
RC
number.
No.
M
The
queue
after
duty
here
but
go
ahead
first
Adam
Adam,
Roach
I,
just
wanted
to
make
a
couple
of
observations.
The
first
is,
we
have
done
standardization
of
things
that
were
pretty
internal
to
systems,
for
example,
sip
standardized,
a
common
logging
format
that
is
used
exclusively
between
like
a
proxy
and
the
file
system,
and
the
tools
have
scraped
things
out
of
the
file
system.
So
it's
not
like
this
is
well
outside
the
spirit
of
what
the
ITF
traditionally
does.
M
The
other
thing
that
I
would
observe
is
that
if
this
group
wants
to
put
together
documents
and
have
them
published,
they
can
even
get
an
RFC
number
on
them
as
long
as
they
work
with
the
independent
stream
editor.
So
that
might
be
a
path
to
consider
if
there's
like,
really
strong
pushback
against
doing
it
in
this
working
group
just
want
to
offer
that
up
as
an
observation.
M
O
Right,
I,
you
know,
I
think
that
what
we
were
trying
to
look
for
in
this
tech,
ops
group-
you
know
speaking
to
Alex's
point
of
like
reports
and
that
type
of
thing
it's
not
really
that
we
were
looking
for
an
RFC
for
the
reports,
an
RFC
number.
We
were
looking
for
some
place
to
put
this
document
as
an
informational
to
say
this
is
how
the
registrar's
would
like
this
to
happen
so
that
when
new
registries
come
online
and
they
ask
for
how
would
you
like
to
have
this
done?
O
We
could
point
to
this
and
say
look.
This
is
what
we
have
in
the
IETF.
It's
an
informational,
it's
not
necessarily
a
standard,
but
this
is
the
way
that
other
registries
have
started
to
take
this
down
now,
I'm
I'm,
not
I,
don't
think
we
were
asking
every
registry
to
do
this,
but
this
is
what
we
wanted
to
have
for
it.
You
know,
as
we
know
there
were
supposed
to
be
thousands
upon
thousands
of
new
TLDs
coming
up
and
I.
O
Don't
know
how
many
registry
operators
there
would
be,
but
we
would
like
to
be
able
to
point
to
somewhere
to
say
this
is
how
we
would
like
to
see
these
these
reports
or
matted
etc,
and
that
was
the
whole
point
of
putting
out
the
the
unavailable
names
list
and
the
the
tiered
prices
list.
I
can't
premium
price
list,
I
guess,
so
we
could
point
to
something
to
say:
here's
the
document
it's
in
IETF,
it's
not
an
RFC,
but
it
is
an
informational
and
that
is
kind
of
a
standard
and
I'm
using
standard
very
loosely.
O
N
N
Again,
here,
I
understand
what
you're,
after
actually
and
it's
perfectly
well
it
because
it
improves
interoperability
and
everything
I'm
as
I
said
I'm,
just
not
sure
we
have
a
very
small
group
here
yeah,
and
that
means
we
have
very
little
reviewing
power
yeah
for
those
documents,
and
we
have
a
lot
of
a
lot
of
existing
documents
which
we
need
to
push
through
publication
process.
So
any
like
a
couple
other
more
documents,
just
because
that's
existing
practice.
That
registrar's
would
appreciate
registries
to
follow.
N
I
wonder
what
we
can
actually
contribute:
yeah,
because
there
are
fewer
people
here
and
around
the
CPH
take-up
groups.
Some
of
the
people
participate
in
both
groups.
So
what?
What
can
that
groove
actually
contribute,
yeah
and
and
how
many
people
here
are
like
in
a
position
to
review
those
three
documents.
I
think
that
you
mentioned
now,
especially
given
the
fact
that
they
were
unable
to
participate
in
the
development
of
these
documents
before
those
documents
were
made
available
to
the
ITF
yeah.
That's
that's!
Actually
what
what
my
problem
is.
A
A
This
is
an
important
discussion
and
I
do
think
that
we're
okay
for
now,
what
I,
what
I
would
suggest
is
I'm
gonna,
look
to
you
know
proposed
the
the
Charter
changes
on
the
mailing
list,
and
let's
use
that
as
an
opportunity
to
talk
about
this
particular
issue,
some
more
it's
it's
subjective,
Alex,
I,
guess
you
know
speaking
a
little
bit
for
myself
here,
not
not
as
chair
again.
You
know
I'm
supportive
of
this
process,
where
we're
trying
to
find
a
way
to
work
more
closely
with
a
community
of
people
that
are
not
easily
accessible.
A
So
that's
one
side
of
things
and
you
know
I
you're,
not
in
your
head.
Just
for
the
folks
who
can't
see
you,
and
so
that's
a
good
thing,
the
the
second
part
of
it
is.
You
know
we
can
have
some
discussion
about
whether
or
not
the
things
that
they're
proposing
really
should
be
IETF
documents
or
not.
Adam
brings
up
a
good
suggestion
about
well,
they
could
just
put
them
in
the
Independent
stream
editor
and
go
that
path.
A
My
you
know,
speaking
personally,
I
would
rather
that
they
come
through
this
working
group
at
least
a
little
bit,
even
if
they
don't
get
much
look
and
then
they
go
out
to
the
IETF
at
large,
because
I'd
rather
they
be
known
invisible
to
all
of
us,
then
that
they
suddenly
appear
somewhere
else.
I
like
the
idea
of
bringing
them
over
here,
because
I
don't
want
to
have
too
many
places
that
I
have
to
participate
for
the
documents.
A
But
we
can
continue
the
discussion
on
the
mailing
list
when
we
get
to
looking
at
the
at
the
Charter
and
think
about
that
and
see
where
we
are
okay,
we
have
20
minutes
left.
So
that's
the
milestone,
review
I
think
we're
in
good
place
we're
going
to
clean
up
our
milestones.
It's
going
to
suddenly
become
very
short.
A
We
have
some
administrative
stuff
with
a
bunch
of
documents
that
has
to
happen
over
the
next
couple
of
months,
but
we
should
have
a
pretty
thin
agenda
moving
into
July,
but
ideally
we
will
have
some
new
documents
that
will
come
to
us
that
we
will
work
to
adopt
and
so
we'll
have
a
new
set
of
documents
and
and
things
to
look
at
coming
into
the
next
meeting
in
July.
So,
okay
on
the
agenda,
we
have
one
other.
We
have
actually
already
talked
about
the
org
documents.
A
I
kind
of
slotted
them
upfront
into
the
milestone
discussion,
so
is,
is
Gavin
here,
Gavin
yeah,
okay,
good.
So
let
me
bring
up
his
slide
here.
There
are
two,
our
slides
that
were
loaded
up
there
for
folks
who
want
to
get
them
and
in
the
meantime
let
me
bring
them
up,
so
I
can
show
them
off
here
and
let
Gavin
go
ahead.
If
you
want
to
wait
for
your
slides.
Just
give
me
a
moment
here.
P
Okay,
thanks
thanks
Jim,
so
I'm
bringing
this
to
this
working
group
because
I
think
is
the
possibly
the
best
fit
for
what
I'm
talk
coming
to
talk
about.
In
that
it's
in
the
area
of
registration
operations,
it's
a
kind
of
thought,
experiment
or
a
straw.
Man
idea
to
kind
of
look
at
the
way
that
we
currently
publish
and
retrieve
registration
data
about
domain
names.
P
P
So,
okay,
so
just
gonna
go
quickly
through
this
talk
about
where,
where
this
came
from,
what
the
current
situation
is,
what
Who
am
I
is
think
a
little
bit
more
about
some
of
the
impacts
it
might
have
and
then
look
at
what
might
be
doing
the
future.
So
you,
the
origin
story,
is
I,
was
browsing
Facebook
quite
late
one
evening
and
a
good
friend
of
mine
who
now
works
in
a
filius
posted
a
link
to
an
article
on
circle.
P
Id
about
how
you
know
gdpr
was
a
terrible
thing
and
who
eliminating
who
is
just
going
to
be
a
disaster,
and
it's
something
just
sparked
in
my
head.
It
might
be
the
wine
I've
been
drinking
saying
well,
let's
think
about.
Let's
kind
of
you
know:
I
was
out
of
the
box,
so
I
thought
out
the
book.
So
I
wrote
this
up.
P
This
little
comment
on
Facebook,
which,
a
few
days
later
kind
of
translated
into
the
next
slide,
which
was
an
internet
draft
I,
don't
know
how
that
happened,
but
the
Facebook
comment
got
turned
into
an
internet
draft.
There
was
another
version
of
this
which
I
published
a
few
weeks
ago,
but
it
is
pretty
much
as
this
is
now.
It's
obviously
there
for
anyone
to
look
at.
So,
let's
talk
about
where
we
are
at
the
moment.
P
Please
thank
you.
So
in
most
cases
registries
operate
databases
of
contact
information.
They
all
run
RFC
five,
seven,
three,
five,
seven,
three
zero:
they
will
have
a
registrant
admin,
tech
and
billing
contact
for
their
domain
names.
I've
done
some
research
in
in
kind
of
usage
patterns
of
contact
objects
in
registries
by
registrar's,
there's
a
great
deal
of
duplication,
there's
a
great
deal
of
wastage,
registrar's,
never
delete
contacts
and
I
literally
mean
never.
P
So.
Registries
have
huge
databases
of
contact
information.
It's
all
low-level
contact
information,
but
they
have
a
lot
of
it
and
if
there
are
gTLD
or
they're
a
registry
that
publishes
their
continent
own
file
or
a
list
of
domain
names,
then
essentially
that
database
is
freely
accessible
to.
Anyone
who
wants
it
or
they
have
to
do
is
just
do
a
foreach
on
every
domain
in
the
zone
and
for
a
data.
Subject,
a
registrant
or
someone
who's
been
roped
in
to
be
the
admin,
tech
or
billing
contact
for
a
domain
name.
P
P
We,
despite
the
capabilities
that
our
app
has
there,
is
still
no
differentiated
access
really,
so
everyone
has
access
to
everything
which
means
that
there's
absolutely
no
incentive
for
anyone.
Who's
being
asked
to
submit
information
to
this
database
to
give
any
accurate
data
other
than
gatekeeper,
saying
that's,
not
valid.
Please
try
again
they'll,
and
we
know
that
Hughie's
accuracy
is
not
great.
P
So
that's
the
current
situation
with
with
the
the
Registration
Data
Services
that
we
have
at
the
moment,
whether
that's
who
is
our
adapt
so
Who
am
I,
starts
from
a
few
basic
principles.
One
get
rid
of
a
centralized
database
to
tell
the
registrants
that
domain
owners
to
publish
the
information
in
a
standardized
format
and
Who
am
I,
provides
a
way
for
a
consumer
of
that
information
to
go
work
out
where
to
find
it.
The
registrant.
The
domain
owner
gets
transparency
on
what's
happening
to
their
data.
They
can
see
who's
requesting
it.
P
So
the
approach
of
a
domain
name
publishes
a
URI
record
at
the
apex
of
their
domain
or
under
it
under
a
tag
that
just
says
this
is
the
URL
you
go
to
to
get
my
contact
information,
so
they
can
put
whatever
information
they,
whatever
your
I
they
like
in
their
it,
could
be
on
on
their
own
web
server.
It
could
be
on
third-party
server.
They
can
put
whatever
they
like
in.
P
It
occurred
to
me,
after
writing
this
that
there's
a
second
version
of
this,
which
is
that
on
the
next
slide,
which
is
actually
just
put
whole
thing
in
the
DNS,
because
you
can
take
a
vCard,
you
can
encode
it
into
base64.
You
can
create
a
data
URI,
so
this
avoids
the
need
to
have
a
file
somewhere.
You
can
just
stick
it
straight
in
the
DNS
and
then
it
also
avoids
the
need
for
the
client
to
your
web
request.
So
the
client
can
just
grab
the
data
straight
out
of
the
DNS.
P
P
So
that's
a
basically
description
of
what
Who
am
I.
Is
it's
it's
very
simple:
it's
if
you're
doing
if
you're
writing
a
who
a
my
client
instead
of
a
who
is
client
instead
of
going
to
a
working
at
which
registry
to
go
and
send
a
a
port
43
request
to
you.
Just
do
a
DNS,
lookup
and
see
if
you
don't
get
a
DNS
lookup,
then
you
can
go
straight
to
this
URL
and
try
and
get
that
as
well.
P
If
you
get
a
404,
then
you
know
that
you've
not
got
you
want
what
you
need
next
slide.
So
what
does
this
mean
for
the
different
parties
involved
for
domain
owners?
They
have
the
obviously
obvious
that
information,
a
lot
of
companies
do
this
already
I
mean
how
many
cut
websites
do
you
go.
We
already
requirement
certain
jurisdictions
require
that
you
publish
it
in
input
in
human,
readable
format.
All
I'm
saying
is:
let's
put
it
in
a
in
a
machine,
readable
format
as
well.
P
The
indirection
allows
you
to
use
a
third
party
or
for
a
third
party,
to
provide
it
to
you
as
a
managed
service.
If
you
register
a
domain
name
with
godaddy
or
with
any
other
registrar,
they
usually
give
you
a
DNS
free,
DNS
service
same
same
time,
and
so
they
can
insert
that
DNS
record
for
you
or,
if
they're,
providing
your
website
a
web
hosting
service,
they
can
set
the
well-known,
URL
and
and
publish
the
information.
If
you,
if
you
ask
them
to,
there,
is
a
possibility
at
some
point
of
providing
some
form
of
federated
authentication.
P
It
allows
the
domain
owner
to
log
who's
accessing
their
Whois
information.
So
they
know
if
someone's
they
can
correlate
it
to
I
got
an
email.
I
published
a
Who
am
I
file
with
this
email
address
in
it.
Someone
from
this
IP
address
did
it,
who
my
query
for
it
and
then
I
got
a
spam.
So
I
know
that
IP
address
was
being
used
to
harvest
information
for
spec,
and
then
you
could
do
clever
stuff
whereby
you
give
different
information
to
different
people.
P
What
does
it
mean
for
registries,
so
registrar's
so
again,
a
registrar's
already
in
the
business
of
capturing
contact
information
from
their
customers
and
giving
it
to
third
parties
under
this
model
they
don't
have
to
give
it
away
to
their
parties.
They
can
keep
it
themselves,
they
can
publish
it.
They
can
provide
that
as
a
as
a
value-added
service
to
their
to
their
customer.
P
So
if
they're
in
a
their
red
selling
a
domain
name,
that's
under
a
policy
regime
that
says
we
don't
have
thick,
who
is
instead,
registrants
have
an
obligation
to
publish
accurate
who
are
my
information.
They
can
register
us,
can
step
in
and
fulfill
that
requirement
and
then,
finally,
for
registries,
so
registries
often
need
to
contact
information
to
validate
credentials
or
eligibility
to
say
make
sure
to
make
sure
they
know
who,
if
the
register
nism
that
they're
there
they
have
the
rights
to
get
that
information.
P
I,
don't
think
who
my
prevents
that
from
happening
at
all,
so
you
could
have
envisage
a
situation
where
the
information
was
presented
to
the
registry
as
part
of
the
Craig
command.
The
registry
then
validates
it
and
discards
it
or
that
the
URL
or
the
DNS
record
is
pre
published
on
the
domains,
name,
servers
before
domains
created,
and
then
it's
checked
in
the
same
way.
That
registry
is
often
check
to
see
that
there's
no
Lane
delegation
before
they
create
the
domain.
P
They
can
pure
Italy
poll.
It
make
sure
that
it's
there
they
can
respond
to
reports
from
third
parties
that
it's
missing
or
it's
bogus
in
the
same
way
that
they
do
with
who
is
currently.
But
it
does
take
a
great
deal
of
burden
away
from
the
registries.
They
no
longer
have
this
huge
database
of
personal
information
that
they
have
to
protect
that
their
it
saves
them
money,
operations
and
security
and
all
kinds
of
other
things.
P
So
that's
kind
of
very
high
level.
What
Who
am
I
could
be
if
we
could
move
on
to
the
next
slide.
Oh
final,
one
is
for
consumers,
so
you
you
can
still
date
in
mind.
Who
am
I
because
you
still
have
a
list
of
zone
of
domain
name,
so
you
can
still
go
out
and
query.
Each
one
you'd
have
to
worry
about
rate,
limiting
because
you're
not
hitting
the
same
Whois
server
every
time,
you're
going
out
across
the
internet
and
getting
it
from
all
kinds
of
random
places.
P
So
you
could
easily
have
a
situation
where
a
browser
has
an
extension
or
some
feature
where,
when
it
hits
the
domain
name,
it
then
just
the
who
and
my
query
in
parallel
saying
where
does
a
query
for
a
for
a
favicon
or
something
like
that
and
just
displays
it
in
the
in
the
in
the
chrome
of
the
browser,
how
you
might
handle
authentication
when
you're,
when
you're
doing
operating
headless
mode
as
goddess
talked
about?
It's
is
a
is
a
question
about.
Is
that
I
can't
give
an
answer
to
here?
P
So
future
I
mean
this
is
still
kind
of
a
silly
toy
I'm,
not
suggesting
that
we
take
this
term
the
standards
track
or
anything
like
that.
But
there
are
possible
ways
we
can
improve
and
enhance
it,
and
this
is
a
list
of
some
of
them.
So
could
we
have
different
contact
types?
How
would
you
retrieve
information
when
it
remains
not
working
anymore
and
I?
Haven't
really
done
a
formal
analysis
of
security
instability
I'm
slightly
scared
by
the
length
of
this
queue.
A
H
H
Type
would
be
cool
to
have
some
sort
of
things
in
x-men,
I,
think
I
said
it's
a
good
idea
to
all
your
people
to
publish
their
own
data
I'm,
not
skeptical
on
the
last
part
that
it's
possible
to
replace
a
current.
Add
yes,
a
typical
example
of
a
problem
in
the
default.
We
don't
publish
a
data
of
personal
registrants
individuals,
but
we
still
need
to
have
it
in
case.
We
have
to
contact
them
so
who
am?
H
I
cannot
replace
that,
but
as
a
possibility
also
for
the
web,
they
have
been
so
many
proposals
have
some
sort
of
humans
that
sixteen
well-known,
so
people
can
publish
in
a
structural
way
information.
It
would
be
cool
to
review
all
these
possibilities
to
be
sure
that
they
work
well
with
your
proposal,
but,
yes,
I,
agree,
I
support.
Thank
you.
Thank
you.
I
You
know:
registrant
information
is
something
that
people
like
to
use
for
spamming.
You
said
that
so
people,
essentially,
if
you
know
registries
and
registrar's,
were
not
publishing
movies
data.
Roughly
speaking,
I
have
some
doubts
that
the
actual
registrants
will
publish
their
own
data.
Therefore,
it
might
be
a
cool.
You
know
cool
idea,
but
who
is
going
to
really
use
this
right?
I'm
skeptical
about
the
actual
news,
so.
P
So,
on
its
own,
Who
am
I
is
not
gonna
solve
is
not
into
any
problem.
It's
say
it
needs
to
come
with
a
kind
of
policy
environment
that
makes
use
of
it.
So
the
there
are
certain
norms
that
are
enforced
by
policy
in
other
areas,
and
that's
all
I
proposed
is
that
if
a
registry
might
make
the
decision
that
they
wanted
to
go
fully
fear-
and
you
know
one
publish
any
odd
store
or
publish
any
contact
information
whatsoever.
They
still
needed
a
way
of
identifying
who
is
responsible
for
domain.
P
J
Scott
Harlan
back
a
couple
of
things,
so
I'm
trying
to
go
very
fast
since
I've
only
got
a
minute
as
I
read
through
this
a
couple
of
words
kept
popping
into
my
head
finger,
webfinger
right,
it's,
it
seems
very
similar
in
constant.
You
know
the
idea
that
you,
as
a
user,
can
self
publish
some
information
and
others
can
find
it
assuming
they
know.
J
You
know
the
right
tool
to
use,
but
the
other
thing
I
wanted
to
say
is
you
know
what
you
just
described
here
in
terms
of
the
registry
kind
of
being
the
enforcer
of
ensuring
that
registrants
do
something
that
scares
me
to
death.
I
could
imagine
it
your
scout,
it
would
write.
Well
you,
as
Mark
was
saying
getting
millions
of
registrants
to
do
anything.
Even
if
there
is
a
policy
Club,
you
can
hit
them
with
it's.
J
It's
a
losing
proposition
and
I
know
that
you
know
my
company
doesn't
really
want
to
have
to
be
in
the
business
of
enforcing
what
a
registrar's
customers
are
doing
or
not
doing
and
I.
Imagine.
The
registrar's
are
probably
a
little.
You
know
nervous
about
the
idea
of
having
to
enforce
what
their
customers
are
doing,
but
as
an
experiment.
It
sounds
kind
of
interesting
yeah,
and
this
is
what.
M
Roach
Adam
Roach
as
an
individual
I,
wanted
to
make
a
couple
of
observations.
The
first
is
so
looking
at
the
NS
records.
You
have
like
a
limit
of
255
by
the
time
you
64,
encode
doesn't
put
in
URL
you're
down
about
160,
and
you
look
at
your
average
vCard
it's
about
four
times
that
so
that,
oh,
is
it
okay,
alright,
so
the.
A
M
I
M
It's
hardly
a
settled
conversation,
but
I
would
encourage
you
if
you
want
to
do
work
that
uses
dot
well-known,
make
sure
you're
on
the
art
at
ITF
org
list.
There's
probably
going
to
be
a
new
list
spun
up
to
talk
about
this,
but
it
would
definitely
bear
on
whether
what
you're
doing
is
going
to
be
permissible
or
not.
Yeah.
P
Q
Actually,
just
share
the
content.
That's
called
the
previous
speaker
well
expressing
that
just
really
an
incentive
for
users
to
put
in
that
data,
or
maybe
I,
don't
see
that
incentive
that
may
lead
to
incomplete
or
even
inconsistent
or
wrong
information,
and
also
like
implying
enforcing
it
by
policies
causing
me
some
headaches.
You're.
Absolutely.
A
Okay,
so
and
Jim
Galvin
speaking
for
myself.
What
I
like
about
this
is
I.
Think
as
Scott
was
saying,
it
looks
like
a
nice
experiment
and,
and
what
I
have
in
my
mind
is
there
are
discussions
on
the
on
the
gdpr
side
of
things
about
there
is
this
distinction
between
legal
persons
and
natural
persons
and
legal
persons
in
some
areas
are
required
to
expose
some
contact
information,
and
it
occurs
to
me
that
this
could
be
a
nice
solution
to
that
you
know.
A
If
your
domain
name
is
associated
with
legal
person,
you
simply
have
to
put
the
contact
information
out
there
for
it
and,
and
that
would
settle
everything.
Then
you
don't
have
to
do
anything
to
the
rest
of
the
registration
system
so
that
that's
at
least
my
suggestion
and
all
this
I
kind
of
like
it.
From
that
point
of
view,
are
you
so
now
coming
back
to
being
a
chair
you're
putting
it
out
here
for
right
now?
Are
you
going
to
ask
for
a
working
group
adoption
here
or
is
that
your
urine
tank.
P
It's
gonna
stay
experimental,
so
I
think
it's
gonna
go
down
the
standards
track.
I,
don't
know,
I'm
not
familiar
enough
with
the
processes
of
the
ITF
to
know
whether
whether
it
needs
to
go.
It
may
be
that
as
a
strawman
exercise,
just
publishing
as
a
draft
and
taking
it
to
a
few
different
places
is
enough
to
get
the
conversation
moving.
That's
that's
really
the
idea
behind
it.
Okay,.
A
So
me
gecko
has
kind
of
ended
on
us
here,
so
in
fairness
to
others.
Let
me
thank
Kevin
for
bringing
this
up
here
and
I.
Think
that,
as
he
said
in
the
beginning,
you
know
you
know
this
thing
would
need
to
exist
in
some
kind
of
policy
context.
So
this
work
to
be
done
here
in
discussions
to
be
had
and
owe
me
deco
seems
to
be
back
because
antoine
is
there.
So
that's
good!
Alright,
I
guess
that's
it.
I
don't
really.
A
Did
anyone
have
any
burning
any
other
business
that
they
have
to
bring
up,
or
can
we
end
since
we're
already
over
and
all
the
noes
are
going
up?
So
that's
great
thanks
very
much
everyone.
The
blue
sheets
are
out
there
somewhere.
Somebody
hold
them
up.
Please
pass
them
to
the
front
of
the
room
if
you
haven't
signed
in
please
do
and
thanks
everyone
appreciate
your
being
here
and
adam.
If
I
could
get
two
minutes
your
time
before
you
leave.