►
From YouTube: IETF104-REGEXT-20190325-1350
Description
REGEXT meeting session at IETF104
2019/03/25 1350
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
C
B
No,
but
seriously.
Yes,
folks
are
used
to
seeing
me
sit
up
in
the
in
the
room
here
at
all
all
by
myself,
and
we
have
the
good
fortune
this
time
of
having
my
coche
here,
our
co-chair.
The
whole
working
group
Antoine,
is
here
and
in
person
at
this
point
in
this
meetings.
All
that
you
say
hello,
I
have
Rowan.
A
D
E
B
F
B
A
B
Since
we're
lucky
enough
to
have
two
of
us
here
this
time,
this
is
great,
so
Antoine's
gonna
do
jabber
scribe
from
up
here.
Sorry
just
took
us
minute
to
make
sure
we
could
get
all
that
set
up
and
make
all
that
work.
So
this
is
the
registration
protocols,
extensions
working
group.
We
have
one
meeting
this
week.
We
got
a
two-hour
time
slot
and
we
actually
have
quite
a
number
of
things
to
go
through
here.
I
suspect,
we'll
fill
up
our
time
slot
and
that's
that's
a
good
thing
because
we're
making
progress.
B
B
D
B
For
the
jabber
sky,
yep
Oh
awesome,
thank
you.
George
I
saw
you
in
the
back
over
there
excellent.
Thank
you
very
much.
You
might
find
it
convenient
to
come
sit
up
front,
so
you
can
get
people's
names
right
when
you
want
to
talk
about
who's
talking
but
or
not
or
not.
It's
up
to
you,
but
thank
you
to
George
or
volunteering
to
do
that
and
no
scribe,
but
Ulrich
is
gonna,
be
our
note-taker.
We've
already
done
the
not
know.
Well
that
can
imagine.
B
Talking
a
bit
about
that
along
the
way
here,
throughout
this
meeting,
we're
gonna
get
to
talking
about
milestones.
The
documents
were
working
on
so
we'll
get
into
that.
As
far
as
the
status
of
all
of
our
documents,
we've
actually
been
quite
productive
here
over
the
past
few
months,
as
we
reach
our
turd
and
cleaned
up
late
into
work
and
have
made
plans
for
future
work
to
come.
So
just
a
quick
look
here
well,
this
is,
is
actually
a
little
bit
out
of
date.
B
We
just
discovered
we
have
a
couple
of
RCS
that
have
been
published
since
our
last
meeting
already
so
RFC
84,
95
and
85
41.
So
we
got
to
work
items
here
off
of
our
action
list
and
our
milestone
list.
We
did
well,
we
used
to
have
three
documents
in
the
arcs.
The
editor
queue
change
poll
is
still
in
the
editor
queue
but
Antoine
just
said,
as
we
sat
down
at
the
table
here,
that
the
organizational
documents
have
now
actually
been
published
on
you
happen
to
know
offhand.
The.
B
I
B
J
B
That's
currently
submitted
for
publication,
and
we
also
have
the
bundling
or
strict
bugling
registration
document
to
be
submitted
as
an
informational
document.
We
had
at
one
time
spun
that
off
in
an
attempt
to
see
if
it
could
be
its
own
working
group
and
since
there
was
no
general
solution
to
this
space,
but
it
was
okay
with
the
IETF
in
the
ISD
in
particular
to
pull
this
back
and
just
make
it
an
informational
document
so
that
it
could
be
a
documented
specification
for
how
the
folks
really
wanted
to
get
this
particular
feature
done.
So.
B
L
Jingled
after
we
did
the
poll
for
the
regex
group,
it
was
pretty
obvious
that
this
particular
extension
didn't
have
much
support.
I
mean
it
got
my
support.
That's
got
Hollenbeck
support,
and
that
was
it
so
in
essence,
that
pretty
much
showed
that
there
was
lacking
interest
in
this
particular
document.
There's
lots
of
items
on
our
queue,
so
my
recommendation
is
to
withdraw
this
document
from
the
working
group.
That's
it.
B
And
we
did
set
aside
a
few
minutes
for
discussion,
but
I'm
guessing
as
James
said,
and
some
moving
it
forward
didn't
seem
to
get
a
whole
lot
of
traction.
It's
not
clear.
We're
gonna
get
a
lot
of
objections
to
withdrawing
it
and
that
does
align
with
our
goals
here
about
future
work.
We
have
a
set
of
things
we
want
to
work
on,
and
so
we
have
to
go
through
the
administrative
task
of
deleting
the
milestone
so
that
it's
off
the
list
and
that
opens
up
that
slot
so
that
we
actually
have
our
five
milestones:
okay.
B
J
M
L
B
Fair
enough
yeah,
thank
you
for
that
clarification,
you're
right.
There
was
some
amount
of
discussion
on
the
list
about
you
know
some
issues,
but
there
didn't
seem
to
be
traction
in
terms
of
the
implementation
and
neat
work
from
registries
and
registrar's.
More
broadly,
so
that's
really
the
particular
detail
to
put
in
there.
So
thank
you
for
that.
Okay,
newly
adopted
documents,
as
you
will
recall,
wrecks
on
slide
11
for
folks
who
are
looking
at
this
remotely
and
maybe
just
listening
now
the
new
documents
work
items
we
had
in
December.
B
You
know
popped
up
and
and
stood
up
as
the
test
that
we
want
to
address.
So
what
we
have
arranged
is
for
a
bit
of
presentation
and
some
discussion
on
each
of
these
documents
so
that
we
can
bring
all
the
members
of
the
working
group
up
to
speed,
get
some
initial
reactions
and
have
some
discussion
about
that.
And
then
our
next
big
agenda
item
here
will
be
to
get
into
talking
about
milestones
and
what
to
do
with
the
discussion
that
we
have
here.
B
So
the
purpose
of
the
set
of
presentations
and
discussions
is
just
to
give
everyone
a
sense
of
the
documents
and
a
sense
of
the
issues.
We
asked
each
of
the
author's
to
bring
to
the
group
here.
What
they
see
has
open
questions
or
issues
that
we
need
to
be
talking
about
here.
So
this
is
not
about
teaching
you
about
these
documents.
Everyone,
hopefully,
has
read
them
in
a
some
speed.
B
This
is
focusing
on
what
are
the
issues
that
we
do
need
to
focus
on
and
have
some
discussions
about,
so
we'll
go
through
these
in
order
that
they
are
here
and
the
first
one
is
the
federated
authentication
for
our
dad
and
his
Scott.
Here,
oh,
oh
there
is
he
sitting
there
hard
to
believe
Scott.
You
are
hiding
behind
Watson.
How
is
that
possible?
B
N
B
Me
and
you
want
to
run
your
own
slides,
you
can,
or
you
can
say
alright.
C
I
can
operate
a
clicker
as
well
as
anybody,
okay.
No,
so
why
things
about
this
document?
Is
it's
not
exactly
a
new
draft?
It's
existed
since
2015
in
individual
submission
form.
I
literally
started
working
on
this
document.
At
about
the
time
that
we
stopped
working
on
the
core,
our
gap,
security
services
draft.
We
didn't
touch
on
this
topic
in
there,
mostly
because
remember
we
were
all
getting
kind
of
tired
of
working
on
the
core.
Specs
basic
and
you
know,
digest
forms
of
authentication
seemed
like
they
were
good
enough
for
the
chorus
pecked
anyway
we
did.
C
We
didn't
have
a
good,
clear
answer
at
the
time
either,
so
it
was
like
okay,
fine.
We
declare
victory.
We
move
on
and
I
started
working
on
this
afterwards.
So
next
so
I
know
Jim
said
not
a
lot
of
presentation,
but
we
I
do
have
a
slide
or
two
of
introductory
material.
So
if
you
haven't
reviewed
the
document,
lately
I
would
ask
you,
please
take
a
peek.
C
It
is
about
federated
authentication,
and
here
I'm
run
by
Federation.
I
mean
we're
talking
about
a
system
in
which
there
are
multiple
parties
collaborating
to
provide
this
particular
function.
You
know,
unlike
digest
or
basic
authentication,
where
you're
kind
of
dealing
with
a
password
exchange
between
a
client
and
a
server.
This
model
has
more
actors
involved
right
and
there
are
certain
benefits
to
that
type
of
an
interaction
certain
drawbacks.
C
It
adds
a
little
bit
of
complexity,
but
for
the
operating
environment
in
which
we
are
seeing
our
DAP
being
used,
it
seems
to
provide
some
very
interesting
properties
that
allow
it
to
scale.
Okay.
The
approach
is
based
on
two
standards-based
technologies,
o
auth
2.0,
which
is
work
happening
right
here
in
the
IETF.
In
fact,
I
think
the
OAuth
working
group
is
meeting
twice
this
week
once
in
the
section
session
after
this
one,
but
also
open,
ID
Connect.
Now,
if
you're
not
familiar
with
Open
ID
Connect,
it's
not
IETF
work.
C
C
The
technique
described
in
the
document
leverages
a
concept
of
identity
providers,
as
I
mentioned
before
scale,
is
an
issue
when
you're
dealing
with
basic
or
digest
authentication.
You
know
as
a
server
operator,
you
know,
my
employer
is
not
really
interested
in
having
to
assign
usernames
and
passwords
to
millions
of
people
with
who
we
have
no
formal
business
relationship.
It
becomes
a
bit
of
a
management
nightmare,
particularly
when
you
have
people
who
very
you
know
they.
C
They
very
chameleons,
often
forget
passwords
and
then
what
they
want
to
do
then
from
there
is
call
a
help
desk
or
something
well.
We
don't
have
to
do
that
with
this
type
of
a
model,
but
this
is
where
this,
this,
this
notion
of
adding
an
additional
actor
into
the
fray.
You
know
become
something
to
consider
the
our
gap.
C
Operators
are
the
relying
parties
in
this
particular
scenario,
and
if
you
want
to
know
what
a
relying
party
is
go,
read
the
open,
ID
connect,
specs
all
right
in
a
nutshell:
it's
the
entity
that
controls
access
to
a
protected
resource
and
it's
the
entity
that
is,
you
know,
quote-unquote
relying
on
the
services
provided
by
the
identity
providers
right
and
it
uses
identity,
authentication
information
that
comes
from
these
identity
providers
in
order
to
make
authorization
and
access
control
decisions
for
the
request,
doors
right.
So
the
server
operator
doesn't
need
to
know.
C
Passwords
right
doesn't
need
to
know
a
whole
lot
about
the,
but
you
know
what
the
person
is
asking
for:
there's
some
trust
in
the
information
received
from
the
identity
provider
right,
but
the
ultimate
decision
about
hey.
Okay,
now
I've
got
all
this
information
about
the
request,
store.
I.
Have
everything
I
need
to
know
to
make
an
access,
control
decision
right?
That's
one
of
the
features
that
we
get
with
this
particular
model.
C
All
right.
As
I
said
this
isn't
new
and
the
fact
that
it's
been
around
for
a
few
years
means
we
actually
do
have
some
existing
implementations.
C
There
are
a
couple
of
servers
that
Verisign
has
operated
over
the
course
of
three
years,
most
recently
in
support
of
ICANN's
gTLD
pilot
program,
but,
prior
to
that,
we
had
been
doing
some
experimentation
with
a
couple
of
CCT.
All
these
that
we
manage,
we
did
what
we
call
a
thin
experiment
with
CCTV
and
for
those
of
you
aren't
familiar
with
the
technology,
we're
talking
thin
registry
versus
thick
registry.
A
thin
registry
is
one
in
which
the
contact
information
is
not
maintained.
C
C
We
also
stood
up
a
server
to
implement
what
we
described
as
a
virtual,
thick
implementation.
Now
one
of
the
nice
features
about
you
know
our
debt
being
a
web
service.
Is
that
when
you
send
a
query
to
some
service
endpoint
that
endpoint,
doesn't
it
necessarily
have
to
be
the
place
in
which
all
of
the
data
lives
and
in
a
model
where
you
have
data,
is
distributed
among
registries
and
registers?
C
So
we
demonstrated
that
concept
here
and
then,
as
part
of
I,
can
detail
the
pilot
program.
We
actually
implemented
a
thick
experiment
with
the
dot
career
top-level
domain.
We
also
did
it
with
common
net,
but
common
net
are
still
thin,
so
this
particular
program
demonstrated
both
thick
registries
and
thin
registries.
We've
integrated
support
for
a
couple
of
identity
providers
that
are
implementing
the
concepts
in
the
draft.
One
was
developed
by
Avaya
Jenny
where's
Mark
blonde
Shea
I
saw
him
here.
He
was
here.
There
is
back
there.
I
know
mark.
C
Did
some
contract
work
I
think
I
can
actually
get.
You
know
through
a
little
bit
of
money,
his
way
to
stand
up
as
an
identity
provider.
We
integrated
support
for
that
into
our
pilot.
Implementation
works.
Just
great
of
Verisign
Labs
also
implemented
an
identity
provider,
but
as
it
turns
out,
because
this
is
standards-based,
you
can
also
use
standard,
OAuth,
open,
ID
connect,
identity
providers
provided
by
companies
like
Microsoft,
Yahoo
and
google.
Now,
unfortunately,
they
aren't
doing
the
stuff
in
the
draft.
C
So
when
you
look
at
things
like
specialized
claims
and
I'm
talking
claims
in
the
OAuth
sense
here,
think
of
them
as
identity
attributes,
you
know
the
things
that
are
necessary
for
a
server
operator
to
know.
If
they're
dealing
with
a
quote
unquote
authorized
client
well,
Google
Microsoft
Yahoo,
they
know
nothing
about
our
DAP
right,
so
the
identities
that
they
manage
will
return.
Information
like
email
addresses,
full
names
addresses
ages.
You
know
what
not
interesting,
not
necessarily
helpful
in
an
our
DAP
context,
all
right,
but
because
it's
a
standard
space
works
out
of
the
box.
C
All
we
had
to
do
is
configure
some
service
endpoints
and
you
can
use
you
know
you
can
sign
in
with
your
Gmail
identifier.
If
you
want
all
right.
Have
you
said
all
that,
though,
over
the
course
of
time
we
found
that
there
are
still
some
things
that
I'm
gonna
need
a
little
bit
of
help
on
in
terms
of
understanding
if
this
approach
actually
works
in
our
operating
environments.
C
The
number
one
bullet
point
here
that
is
going
to
drag
this
out
for
a
while
is
ongoing
policy
development
work,
particularly
in
an
ICANN
context
right
so
right
now
the
document
describes
a
proposal
for
a
set
of
claims
and
again
claims.
Think
of
them
as
like
identity,
attributes,
you're
things
that
would
be
necessary
for
a
relying
party
to
make
an
access
control
decision
based
on
a
query,
and
so
these
are
things
like
the
purpose
of
the
query.
The
role
of
the
requests
are
in
the
future.
C
It
could
be
like
the
legal
jurisdiction
from
which
the
query
is
coming.
I,
don't
have
a
good
sense
yet
of
whether
or
not
the
set
of
claims
that
are
proposed
in
the
document
is
complete.
Actually
I
take
that
back.
I
have
a
very
good
sense
that
it's
probably
not
complete
and
probably
not
completely
accurate
right,
and
that's
because
the
ICANN
policy
folks,
you
know
who
are
kind
of
chewing
on
this
subject,
haven't
gotten
to
this
particular
tripping
point
yet.
But
it's
something
they're
going
to
be
dealing
with
and
I,
don't
almost
a
relatively
short
order.
C
C
There's
also
been
a
bit
of
a
question
in
my
mind
about
how
we
deal
with
non
browser,
clients,
the
open,
ID,
Connect
and
OAuth
stuff.
If
you
go,
you
know
sit
in
the
session
upstairs
wherever
they're
going
to
be.
You
will
get
a
very
strong
sense
that
they
are
very
browser
centric.
You
know
they
think
of
clients
as
having
easy
access
to
a
web
browser
and
for
their
part
of
the
world
that
works
for
our
DAP.
C
Not
so
much
remember
we
come
from
an
operating
environment
in
which
people
are
used
to
using
things
like
command-line
clients
for
Whois
queries,
or
imagine
that
you're
developing
some
type
of
a
custom,
client
I,
know
Andy
Newton's
got
a
client.
You
know
that
he's
developing,
it's
not
a,
and
so
when
you
have
a
flow
like
an
OAuth
flow
that
expects
you
know
there
to
be
a
browser
there
so
that
you
can
put
information
in
front
of
a
human
and
collect
information
from
them.
C
It
doesn't
always
work
quite
like
you
would
expect,
and
so
right
now
the
document
describes
something
called
the
OAuth
device
flow
and
again,
if
you're
familiar
with,
what's
going
on
with
the
OAuth
working
group,
they've
got
this
they
other
than
actually
calling
it.
The
device
flow
anymore
that
the
device
authorization
flow
anyway.
It
just
popped
out
as
an
RFC
very
recently
and
they
change
the
name
in
the
process.
C
But,
strangely
enough,
even
though
they
claim
that
this
is
a
flow
for
UI
Limited
devices
like
smart,
TVs,
etc
browser
devices
that
don't
have
a
browser,
they
expect
that
you
have
access
to
a
second
device
like
a
phone
that
has
a
browser
to
make
it
work
all
right.
So
the
document
describes
two
approaches.
One
is
this
device
flow,
whether
it's
necessary
or
not?
I,
don't
know,
but
there's
also
descriptive
text.
That
explains
how
you
can
get
around.
C
You
know
doing
what
you
need
to
do
without
a
browser,
and
it
involves
the
ability
to
fetch
tokens
and
store
them
locally,
so
that
when
you
need
to
provide
them
as
part
of
a
query,
you
can
include
them
in
your
your
path,
segments,
okay,
so
that
that
that's
text
worth
looking
at
mentioning
path
segments
I
have
no
idea.
If
what
I've
got
there
is
complete
and
correct,
you
know
for
the
for
the
operating
environment
in
which
we're
trying
to
work.
C
C
C
You
know
by
hex
encoding
the
things
and
stuffing
them
into
the
past
segment
as
a
query
parameter
okay,
that
works,
but
it's
not
really
kosher
from
the
way
Oh
off
those
things
today.
Hoth
says
that
if
you
look
at
access
tokens,
you
know
bearer
tokens,
they
are
typically
pushed
in
an
HTTP
authorization,
header
right
and
the
identity.
Information
like
in
this
case
the
ID
token,
would
be
encoded
and
passed
as
a
query
parameter.
So
I've
got
a
pretty
strong
suspicion
that
I'm
gonna
have
to
get
into
the
document
and
change
the
text
there.
C
C
So
those
are
the
open
questions,
at
least
the
ones
that
I'm
aware
of
and
I
think
that's
actually
last
slide.
I
do
believe
all
right,
I'm
clicking
nothing's
happening
so
alright.
So
that
being
the
case,
any
discussion,
Adam
Adam
Roche
as
an
individual
I,
just
wanted
to
point
out
you're
talking
about
putting
parameters
on
URLs.
If
you
go,
read
BCP
190
and
make
certain
that
what
you're
proposing
is
in
line
with
what's
described
in
there
at
all,
they
would
help
prevent
problems
at
iesg
evaluation
time.
All
right.
Someone
please
take
notes
capture
that
BCP
number.
O
C
Argument
for
me
and
I
have
to
admit
that
over
the
course
of
the
last
four
years,
I
have
I
reached
out
to
the
fellows
in
the
OAuth
working
group
more
than
once
asking
for
a
little
bit
of
cross
area
review
here.
It's
like
guys,
please
make
sure
that
what
doing
his
kosher,
because
at
some
point
you
know
like
to
Adams
point
when
this
goes
up
for
ietf
last
call
or
iesg
evaluation.
One
of
the
worst
things
that
can
happen
is
someone
who
knows
what
they're
doing
looks
at
this
and
says:
are
you
you
know?
C
What
are
you
smoking,
Hollenback
right
as
I?
Nothing
in
particular,
I've
asked
for
help
before
and
I've,
never
gotten
it.
You
know
so
I'd
rather
get
those
surprises
early
in
the
process
rather
than
late,
but
so
that's
why
the
device
flow
was
in
there
right
now,
because
when
I
went
back
and
talked
to
those
guys,
I
think
I
actually
cornered
them
at
the
Berlin
meeting,
which
was
a
couple
of
summers
ago,
if
you're
again
thinking
about
how
long
this
has
been-
and
they
said
well
we're
working
on
this
solution
that
doesn't
require
access.
C
You
know
to
a
browser
for
these
UI
constrained
things
well,
device
flow
is
what
they
came
up
with,
and
so
I
thought.
Okay
in
the
interest
of
trying
to
head
off
that
crossed
area
review
question
it's
in
there
for
now,
but
I
think
we
could
make
a
case
that
it
doesn't
need
to
be
there
because
it
doesn't
work
in
our
particular
environment.
So
thanks
Andy.
B
If
I
may
Scott
so
Jim
Galvin
is
an
individual.
The
question
that
comes
to
my
mind
in
this
issue
of
device
flow
is
there
are,
is
use
cases
that
are
not
browser-based
right,
so
I
mean
we're
used
to
in
in
in
the
Whois
place
of
the
world.
You
know
they're
doing
screen
scraping
of
what
they're
getting
but
I'm
thinking.
You
know
our
DAAP.
You
know
for.
B
A
category
of
being
an
api,
if
you
will-
and
you
think
it
in
those
senses-
there'll
be
other
kinds
of
clients,
and
we
know
in
the
in
the
ICANN
space
there
will
be
other
kinds
of
clients,
reputation
providers.
So
I
I
worry
about
that
interaction.
And
that's
that's
the
question
that
comes
up
in
my
mind
when
you
bring
up
the
vise
flow
and
I'm
thinking.
Well,
I
want
to
think
more
about
that
and
and
look
at
this
again
in
more
detail,
but
that
I
think
is
an
issue
that
we
probably
have
to
deal
with.
C
And,
and
for
what
it's
worth,
if
it's
helpful
I
actually
have
an
implementation
of
the
device
flow
that
you
know,
people
can
play
with,
and
so
it's
easy
to
look
at
the
text
and
say:
I
really
don't
quite
grok
this.
If
you
want
to
see
what
it's
really
like,
you
know,
put
your
hands
on
it,
touch
it
and
get
and
get
a
feel
for
it.
Just
let
me
know
send
me
a
mail
note
afterwards.
I
can
I
can
point
you
to
some
code
that
my
my
engineering
team
developed
that
implements
it
yeah.
So
I.
O
Want
to
design
it
again,
I
want
to
talk
about
the
non
browser
clients
being
an
author
of
a
non
browser.
Client.
One
of
the
things
I've
been
thinking
about
is
how
you
do
how
authentication
would
work
and
it's
probably
going
to
be
in
a
configuration
file
somewhere,
so
I
mean
the
device
flow
is.
Is
it
while
it's
for
non
browser?
Clients
is
also
still
for
interactive
sessions,
and
so
a
lot
of
the
things
we're
talking
about
are
not
interactive
at
all.
It's
automation
or
I
mean
the
case
of
my
client.
O
It's
not,
it
is
interactive,
but
it
works
differently
than
what
you
would
see
with
like
a
Smart
TV,
or
something
like
that.
So
the
way
I
think
client
implementers
would
think
about
this
is
they
would
have
a
configuration
file,
so
this
access
token
or
this
API
key
is
for
this.
You
know
server
or
whatnot,
so
when
they
end
up
hitting
that
server,
although
this
know
to
go
ahead
and
apply
that
so.
B
P
Rick
Rick
Wilhelm
Verisign
just
a
point
of
clarification.
Something
I
know
that
you
know,
but
the
rest
of
the
room
might
not
know.
When
you
talk
about
the
ongoing
policy
development
in
the
ICANN
context.
That's
not
necessarily
I
can
the
organization
but
I
can
as
the
multi-stakeholder
model
that
does
that
policy
development.
So
it's
not
waiting
on
I
can
org
to
do
that,
but
it's
waiting
on
the
ICANN
community
to
sort
that
out
thanks.
Q
Alex
me
over
nico
de
t,
coming
back
to
the
question
of
device
flow,
so
I
I
agree
with
what
NDS
said
and
and
I
think
that
there
will
be
an
out-of-band
process
for
people
who
to
fall,
queries
like
registrar's
or
whatever,
and
they
cannot.
J
Mutual,
if
season
ik
I
recall
those
discussions
around
the
Berlin
meeting
with
the
people
from
where
he
connect
and
I
think
that
one
of
the
points
where
we
were
had
a
problem
to
to
get
into
this
at
the
same
point
was
when
we
start
to
talk
about
the
restfulness
of
arab-arab
service
that
there
was
a
the
problem.
I
think
that
we
maybe
try
to
too
much
in
system
to
have
the
restful
service.
J
While
they
may
be
expected
that
what
why
not
to
do
it
as
a
service
that
you
can
log
in
and
get
the
session
to
have
a
session
and
then
communicate
about
session
and
I.
Don't
know
if
this
has
moved
so
over
the
time.
If
we
still
like
insist
that
this
must
be
a
session,
less
restful
service
or
not.
Maybe
when,
when,
when
we
go
adopting
in
this
point,
that
it
will
be
much
easier
for
implementing
these
kind
of
things
like
authentication
and
things
like
this.
Ok.
C
C
Yeah
that
that
first
bullet
with
this
stuff
on
the
claims-
that's
probably
gonna-
be
the
long
tail
of
the
discussion.
So
I'm
not
looking
to
start
that
one
up,
but
the
the
device
flow
stuff,
the
path
segments
stuff.
You
know
the
query
parameter
ID
token
stuff,
that's
what
I
want
to
bang
on
real
first,
because
I
think
those
are
questions
we
can't
answer,
and
so
we
can
make
those
you
know
deal
we
need
to
do
in
the
deck
there
are
not
the
deck
do
in
the
document
really
quickly
and
then.
C
Lastly,
this
concept
is
being
taken
up
in
the
ICANN
world
today,
if
you're
following
what's
happening
with
ICANN-
and
you
know
the
e
PDP,
you
may
know
that
I
am
part
of
something
called
a
technical
study
group
that
was
asked
by
ICANN's
CEO
to
come
up
with
a
proposal
for
a
technical
model
to
implement
something
that
I
call
I
can
is
calling
a
unified
access
model.
Google,
these
terms,
guys,
okay,
I'm,
not
gonna,
spend
any
time
explaining
it,
but
but
I
bring
this
up,
because
this
draft
is
ultimately
at
the
core
of
the
model.
C
The
TSG
is
proposing
right
and
two
weeks
ago
in
in
Kobe,
this
TSG
had
an
opportunity
to
present
the
model
to
the
community
for
conversation
in
feedback
and
in
some
ways,
I
think
the
good
news
is
the
technical
parts
of
our
proposal
have
so
far
survived.
First
contact
with
the
enemy
right.
Most
of
the
comments
we
got
back
had
nothing
to
do
with
the
technology.
It
was
more
focused
on
things
like
well
where'd.
Your
assumptions
come
from.
You
know,
where's
the
policy
development
going
to
happen.
You
know
stuff
like
that.
C
So
I
I'm
cautiously
optimistic
that
what
is
here
is
actually
ultimately
going
to
be
useful
and
used
right.
So
this
isn't
this
a
sort
of
work,
we're
just
going
to
be
doing
in
Italy
it'll
be
parts
in
place
to
never
see
the
light
of
day
so
anyway,
I
look
forward
to
engaging
you
some
conversation
with
you
all
I
look
forward
to
your
feedback.
Thank
you
very
much
for
the
time.
B
R
R
R
R
R
If
sorting
a
page
information
should
be
provided
in
metadata
elements,
and
if
yes,
if
the
working
group
agrees
about
the
proposed
structure
and
if
this
method
elements
should
be
part
of
a
more
general
metadata
section
together,
including
other
contents,
like
rate
limits,
information
about
server
records
and
response
another
metadata
and
which
pagination
matter
should
be
defined.
Only
one
above
I.
R
L
D
R
L
R
But
I
think
that
in
each
service
should
provide
the
user
with
some
capabilities,
these
companies
can
be
different.
So
if
you
want
to
probably
if
you
are
able
to
to
implement
both
sorting
a
big
information,
you
can
but
it's
on
your
own
to
establish
what
you
want
to
implement.
What
what
set?
What
capabilities
you
want
to
provide
the
video
with
your
clients
with
your
users?
Okay,
well,.
O
R
The
problem
is
that
when
you
submit
a
query
the
first
time,
you
cannot
report
your
paging
parameters,
so
it
is
something
that
the
the
server
provides
to
you
when
the
response
is
truncated.
So
you
can
choose.
For
example,
if
you
sort
for
properties
that
is
not
mapped
on
an
index
at
the
unique
field,
for
example
like
registration
date,
you,
the
cursor
base
position,
is
not
suitable,
so
you
are
forced
to
use
offset
based
pagination.
O
S
O
I,
don't
really
have
a
problem
with
that,
but
it
sounds
like
we
might
want
to
get
into
a
discussion
about
how
servers
can
say
what
their
capabilities
are,
because
you,
you
wouldn't
want
an
interaction
where
you're
just
going
back
and
forth
just
trying
to
figure
something
out
and
it's
never
reaching
a
result.
Yes
and
I.
Don't
know
if
that's
right
for
this,
but
that
may
be
some.
T
Time
we
want
to
discuss
the
information
provided
by
cars.
R
Of
base
fascination
and
offices
very
passionate,
they
are
the
same
quite
the
same,
so
you
had
to
scroll
the
the
page
just
clicking
or
just
to
acting
on
the
next
page
link
that
is
the
same
in
in
both
in
both
modulation
methods.
So
I
think
that
the
survey
is
is
free
to
decide
according
to
they
submit
the
query,
submit
a
query
which
pagination
method
is
is
better
okay,
but
if
you
so.
B
L
J
L
L
R
That
I
cannot
decide,
which
is
the
best
method,
because
both
to
meters
a
as
pros
and
cons,
so
my
my
opinion
is
that
led
you,
P
or
other
operators
to
implement
their
own
Middle's
according
to
de
base,
kills
according
today,
the
information
according
to
how
the
information
is
representing
in
their
own
databases.
So
I
think
that
anyway,
it
is
a.
R
P
Seconds
very
much
Rick
will
embarrass
and
one
thing
that
I
would
offer
we're
talking
about
differentiated
capabilities
per
server
and
and
yeah.
You
interrogate
that
the
one
thing
I
also
some
of
these
servers
will
under
operate
under
contractual
SaaS,
and
so
they
might
have
response
time
requirements
that
they
needed
to
hit
and
so
therefore
they're
there
is
there
a
mechanism
to
adjust
the
capabilities,
dynamic,
dynamically,
to
say
to
look
right
now:
I'm,
really
busy
and
so
I'm
I'm
not
going
to
do
sorting
and
paging
I'm.
B
I
think
the
point
that
I
want
to
capture
in
this
is
you
have
your
last
question
about
which
pagination
method
I
think
there
are
some
sub
questions
here
right.
One
some
question
is
the
interaction
between
the
client
and
the
server
and
what
that
they
know
what
you're
doing
and
how
they
know
and
and
Rick
is
bringing
up
the
additional
subsection
of
what
happens
if
that
changes
during
the
operation,
and
so.
R
R
The
second
draft
is
about
partial,
partial
response.
The
basic
idea
of
this
draft
is
quite
simple.
Instead
of
declaring
explicitly
they
the
data
fields
to
get
back,
the
current
declares
a
name
identifying
a
server
predefined
set
of
data
fields,
so
a
new
parameter
has
been
defined
and
called
fieldset
and
free
fit
set
have
been
defined
to
be
required
at
least
ID.
It
contains
only
the
key
field
brief.
R
We
must
note
that
the
object
class-name
is
implicitly
included
in
each
field
set
that
field
set
should
be
provided.
According
the
user
access
levels
at
least
the
full
field
set
service
may
add
any
service,
information
and
information
that
any
any
field
in
the
response
that
does
not
provide
information
about
the
object,
but
only
service
information
and
implement
an
additional
field
sets,
but
service
should
should
also
define
a
default
of
each
set.
R
So
the
client
you
know,
according
to
the
the
information
provided
by
the
server
in
the
response,
which
is
the
they
fit
set
the
the
survey
as
returned
in
the
response.
In
his
response,
new
properties,
a
new
property
has
been
defined
as
well
called
the
submitting
metadata.
As
a
consequence,
a
new
duck
adopt
conformance
tag
in
India.
R
The
the
point
of
this,
the
discussion
point,
according
to
the
author's
opinion
should
be
which
field
set
should
be
defined
by
this
by
this
draft,
which
response
elements
should
they
contain
and
which
ones
should
be
required.
We
we,
as
Otis
we
we
made
the
proposal,
but
we
are
open
to
obviously
to
update
this
proposal.
According
to
the
working
group
opinion.
R
Since
relationships
exist
in
adapt,
should
we
define
variance
according
to
weathers
associated
objects,
are
written
or
not,
because
we
can
have
according
to
the
fact
that
we
return
them
for
the
Associated
object
or
not
a
range
of
different
solution.
So
we
can
have,
for
example,
a
brief
response
which
does
not
return
any
information
about
the
Associated
objects,
or
we
can
have
a
brief
information
written
in
the
information
about
if
associated
the
object
in
ID
format
and
on
should
the
available
fields
that
be
providing
in
metadata
element.
And
if
he
s.
B
L
As
Jim
goes
from
Verisign
yeah,
this
is
fun
in
the
a
similar
category
as
the
prior
one
we're
in
essence,
if
you
try
to
put
the
policies
associated
with
each
one
of
these
kinds
of
field
sets
into
the
draft
in
essence,
I,
don't
it
may
not
be
feasible,
because
the
actual
servers
are
gonna
have
what's
returned
based
on
policies
at
the
server.
What
they
need
to
meet
so
may
be
better
to
provide
a
way
to
define
and
from
the
client
what
field
set
to
use,
but
then
allow
for
the
server
to
inform
similar
with
talking.
L
L
L
G
O
So
this
is
work.
This
is
Andy
Newton,
so
I
kind
of
disagree
with
Jim
here
the
I
guess
both
Jim's
the
I.
Think
if
it's,
if
it's
kind
of
understood
what
the
expectation
is
in
a
draft
or
something
like
that
or
an
eye
on
a
registry,
then
that's
good
enough
for
the
client.
Yes,
because
server
policy
may
override
that
is,
is
I
mean
that's,
that's
always
a
given.
That's
always
going
to
be
true,
regardless
of
what
an
RFC
says.
O
So
server
policy
says
you
can't
show.
So
you
know
phone
numbers
or
whatnot
and
the
field
set
includes
phone
numbers.
It's
just
not
gonna.
It's
just
not
gonna
happen,
but
I
think
the
thing
is
as
long
as
the
client
knows
what
is
normally
expected
as
long
as
that's
a
standard
somewhere
I
think
that's
good
enough.
R
The
each
segment
new
but
segments
use
a
reverse
search
pattern
and
the
research
pattern
is
a
JSON
object,
including
two
members
value
and
the
role.
A
role
is
a
string
whose
possible
values
are
those
details
in
action.
Ten
point
two
point:
four
of
our
RFC
74,
eighty-three
I
mean
Rossella
registrant,
technical
registrant
zone
and
the
value
represents
the
search
funnel
button
to
be
measured
by
the
corresponding
entity.
Profit.
It
can
be
for
the
first
three
puffs
a
string
and
for
the
fourth
path,
but
it
was
an
object
because
the
address
is
an
object
itself.
R
R
R
U
Bots
Maya
sorry
I,
won't
reply
to
the
questions,
because
first
I
have
a
big
problem
with
the
privacy
considerations
section.
This
possibility
is
really
really
dangerous.
There
is
a
lot
of
potential
for
constant
harassment,
find
out
all
the
domains
of
one
person
and
then
take
a
complete
picture
of
this
person.
U
There
is
a
privacy.
Consideration
is
just
a
remember
that
you
have
to
follow
the
law
on
the
photos,
the
relevant
law,
etc.
It
my
opinion,
the
privacy
considerations,
section
needs
also
a
clear
analysis
of
the
risk,
not
just
saying
that
you
must
follow
the
law,
because
you
must
always
follow
it's
useless
to
United
and
a
clear
analysis
of
the
risk
on
also
an
explanation
of
what
should
be
the
default
policy.
R
We
reported
in
the
privacy
consideration
section
what
should
be
the
hopefully,
these
scenarios
for
the
application
or
these
drafts.
So
we
know
that
there
are
some
potential
risks
in
the
implementation
of
these
all
these
capabilities,
but
we
know
also,
there
are
some
rules
outside
the
scope
of
our
dub
and
fpp
absurd,
this
the
scope
of
technical
or
technical
definition
that
we
don't.
R
R
We
don't
want
to
define
something
that
is
against
the
rules
of
each
country's.
Ok,
we
don't
want
to
we.
For
example,
we
in
Italy
we
have
strict
rules
about
privacy,
okay,
so
when
we
basically,
when
we
fought
to
this
to
these
capabilities,
we
thought
to
the
Registrar
possibilities
to
query
their
own
domains
known
the
domains
are
sponsored
by
the
other.
Ok,
they
asked
some.
R
B
Yeah,
since
you
said,
for
example,
I'm
sorry
I
mean
we
are
running
now
actually
late
here.
So
maybe
if
we
can
just
run
through
the
queue
and
get
all
the
comments
and
we'll
give
you
a
chance
to
give
one
last
reply
to
to
everything
and
then
we'll
move
on
stiffing.
If
you
want
to
you,
want
to
give
a
response
err,
you
can
and
then
we'll
just
run
through
the
rest.
And
then
you
can
reply
to
everyone
at
once.
No.
R
M
Sugar
growers
and
defined
in
attend
society
I
completely
agree
with
stiffer
and
I'd
add
that
the
sort
of
actionable
recommendation
that
the
privacy
considerations
make
can
be
reflected
in
the
technical
details
as
well.
So,
for
example,
the
reverse
search
string.
It
has
the
role
parameter
as
well,
so
I
mean
the
privacy.
Consideration
says
that
it
is
recommended
that
only
specific
entities
can
perform
this
function.
Then
the
role
parameter
should
also
be
recommended
or
required,
rather
than
leaving
it
as
optional
right
yeah.
Q
Alex
may
offer
two
short
points.
One
I
think
that
the
privacy
considerations
section
is
definitely
not
not
sufficient
for
that
protocol,
because
it's
a
risky
protocol
from
privacy
perspective
and
the
second
one
I
would
like
to
really
see
a
single
sentence
in
the
document
that
says
it's
perfectly
fine
to
implement
just
a
subset
of
what
is
specified,
because
otherwise
one
could
get
the
impression
that
a
compliant
server
or
client
whatever
would
need
to
implement
all
of
the
search
options.
J
Q
B
R
L
In
lieu
of
time,
I'm
going
to
jump
through
this,
this
is
pretty
much
a
summarized
presentation
that
I
gave
the
last
ITF,
but
now
that
it's
a
working
group
document,
I
thought
it
was
worthwhile
to
just
review
the
features
of
this
draft.
If
you
haven't
had
an
opportunity
to
review
it
first
off,
there
are
three
problems.
This
draft
is
solving
I'm
gonna.
Do
this
real
quick?
The
first
is:
the
RFC
only
supports
passwords
up
to
16
characters.
That
is
a
big
issue
that
this
extension
addresses.
L
The
next
is
to
allow
the
server
to
provide
to
the
client
any
server
security
events
that
have
been
identified.
There's
a
slew
of
them
that
are
identified
within
this
draft
and
it's
customizable
to
support
others
as
well.
The
last
one
is
kind
of
support
returning
security
event
inspector.
The
client
is
to
allow
the
client
to
inform
the
server
about
it
about
like
what
OS
is
on
what
language,
what
SDK
is
being
used
to
help
identify
issues.
L
The
next
one
is
a
little
bit
more
complex
but
very
extensible,
but
the
idea
is
for
the
server
to
allow
or
to
identify
security
events
that
can
be
returned
back
to
the
client.
Examples
is
if
there's
a
password
expiry
policy
it's
in
place.
If
the
client
certificates
expiring
those
sorts
of
things,
the
server
can
tell
the
client
about
it.
L
So
I
list
out
the
items
that
were
discussed
on
the
list
before
this
draft
became
work.
Your
document
there
was
already
discussion
and
items
that
have
been
addressed.
Specifically,
we
had
discussions
around
the
minimum
length
of
the
password
we
went
with
what
was
in
the
RFC.
There
was
some
tactical
issue
with
one
of
the
elements
also
not
allowing
for
passing
of
an
empty
element.
We
added
in
or
modify
the
security
considerations
section.
The
other
thing-
that's
not
specific
to
this
draft,
but
to
any
EPP
draft,
is
to
have
the
namespace
EPP
scoped.
L
So
we
did
that
so
many
items
that
were
discussed
on
the
list.
We
there
have
been
responses
to
so
I'd
like
to
learn
more
about
whether
or
not
these
are
applicable
or
not.
One
was
discussing
supporting
other
authentication
mechanisms
if
there's
some
ideas
around
whether
or
not
that's
needed
or
not,
for
EPP,
that
would
be
great
and
whether
or
not
it
fits
into
this
draft.
The
other
one
was
use
of
this
constant.
This
bracketed
login
security
to
identify
to
the
server
to
look
into
the
extension
for
the
password.
L
L
I
think
that's
how
it's
pronounced
for
C
framework
and
reviewing
those
RFC
I,
really
didn't
see
any
applicability
to
EPP
passwords.
So
if
there's
any
idea
as
far
as
how
that
is
applicable,
that
would
be
great
to
understand
so
in.
In
summary,
this
particular
extension
saw
also
three
problems
by
extending
the
login
command,
login
response
and
I
highly
encourage
you
to
review
this
and
provide
feedback.
If
there's
any
additional
issues,
I'd
be
more
than
happy
to
I
disgust
them.
That's
it.
V
Robert
story:
USCIS,
I,
I,
read
the
draft
this
morning
and
I
came
in
here
with
the
idea
bring
up
the
pretty
much
the
same
issues
just
discussed
in
the
last
three
drafts
about
capabilities,
and
particularly
with
the
password
complexity,
requirements
not
met.
I'm
sure
we've
all
been
on
web
pages,
where
we
type
in
a
password,
and
they
say
not
good
enough,
but
you
don't
know
why.
L
W
Hello,
this
is
Marty
cousin
Olaf
from
switch
I
have
a
question
about
the
agent
field.
This
is
I,
think
free
text
in
the
draft
field-
the
agent-
oh
it
yes,
we're
actually
declined
can
put,
which
OS
and
which
technology,
for
example,
Java
he's
using.
If
that
should
not
be
more
structured,
to
also
make
it
easier
for
the
server
to
extract
this
data.
Yeah.
U
Stefan-Boltzmann
yeah,
of
course,
this
draft
is
a
very
good
idea.
Everyone
remembers
the
attack
against
a
big
list
well
last
year
with
consequences
for
domain
in
the
Middle
East,
but
for
the
advice
in
security,
consideration
I
think
because
the
problem
of
password
is
a
very
general
problem,
not
specific
to
EPP
I
would
prefer
any
specific
advice
to
be
moved
outside
of
the
security
consideration
on
replaced
by
a
pointer
to
a
more
general
document.
I'm
sure
there
are
many
documents.
U
What
city
one
current
advice
in
security
consideration,
for
instance,
is
that
you
must
not
reduce
the
length
of
a
password
which
doesn't
seem
all
right,
because
if
you
have
a
bad,
a
very
simple
password
of
C
in
character,
replacing
it
by
a
passel
of
15
characters,
but
with
better
and
4p
is
a
good
thing.
So,
instead
of
redoing
the
walk
of
password
strength,
analysis
I
think
we
should
just
point
to
a.
B
B
So
Antoine
and
I
have
been
talking
about
this
a
lot
over
the
last
couple
of
months.
As,
as
folks
know,
we
did
a
a
poll
back
in
December
for
folks
who
were
active
back
then,
and
we
had
21
documents
on
the
list,
and
and
so
we
did
it
all
to
get
people's
idea.
You
know
what
they
thought
they
preferred
in
terms
of
what
we
wanted
to
work
on
in
the
working
group
and
something
interesting
happened
in
that
space,
and
that
is
that
they're
apparent
there.
B
There
was
some
clear
you
know:
dominance
on
the
on
the
our
tap
side,
as
opposed
to
the
registry
and
registrar
option
side
in
terms
of
work
to
work
on.
There
was
quite
a
split
in
documents:
I
mean
there's,
probably
a
half
knock,
you
have.
The
documents
were
for
our
tap
and
and
half
the
documents
that
were
there
were
really
for
registry
registrar
interactions.
B
That
I
can
tell
you
that
in
the
background
we
have
had
multiple
discussions
with
a
with
a
few
different
people
about
the
fact
that
all
of
those
registry
documents
then
just
kind
of
get
put
on
the
back
burner,
and
and
what
happens
you
know
and
why
are
they
sitting
there
and
and
and
how
are
we
ever
going
to
get
to
them
and
we're
not
going
to
do
them?
So
all
of
this
kind
of
you
know
came
together
last
night.
B
The
first
bullet
up
there
says
proposal
before
the
meeting,
because
if
you
were
actually
reading
the
agenda
before
the
meeting
we
had
said
in
the
agenda
the
comment-
and
there
was
that
we
would
put
something
up
to
the
working
group.
You
know
a
week
ago
give
you
a
week
to
sort
of
look
at
something
in
detail
about
what
we
could
do
here.
B
That
we
got
a
suggestion
from
an
area
director
and
probably
I'll-
do
a
little
bit
of
a
side
tangent
here
and
point
out
that
our
area
director
is
going
to
change.
So
I
know
that
we
do
have
Adam
in
the
room
here,
but
we're
going
to
get
a
new
area
director,
berry,
Lima,
they're,
just
going
to
transition
the
working
groups
around
a
bit
and
do
a
little
bit
of
restructuring,
but
they've
gotten
an
idea
about
how
to
deal
with
this.
And
no.
B
He
simply
had
suggested
to
us
that
we
just
have
to
face
the
fact
that
we
have
two
streams
here,
and
it
is
ok
and
in
fact
a
good
thing
for
us
to
deal
with
both
equally
and
give
both
a
chance
to
move
forward.
In
some
sense,
there's
a
little
bit
of
overlap
in
people
that
are
interested
in
both
streams,
but
there's
a
set
of
people
interested
in
one
and
a
set
of
people
interested
in
the
other.
So
it's
possible
from
a
working
group
point
of
view.
B
As
long
as
there
are
people
who
want
to
progress
the
work
to
let
both
sets
of
work
move
forward,
and
so
that's
really
the
proposal
that
we
want
to
put
here
in
front
of
people,
so
there
needs
to
be
a
little
bit
of
a
shift
in
the
set
of
documents
that
we
have
that
want
to
work
on
and
I
see
somebody
running
to
the
mic.
So
I'll
pause
for
a
moment
before
I
get
to
my
next
slide.
Ok,
George.
B
X
X
The
business
work
that
is
exceptionally
important
for
the
correct
operation
of
an
industrial
space,
it's
business
and
it
has
to
be
properly
standardized,
and
it
has
to
be
understood
so
I'm
not
trying
to
say
that
stuff
doesn't
matter,
but
I
do
feel
an
incredibly
strong
focus
in
my
own
heart
to
our
that,
and
the
document
bombing
is
a
reflection
of
a
wider
interest
emerging
from
ICANN
community.
That
is
essentially
we
have
to
get
out
of
who
is,
and
that
problem
has
been
a
15
to
20
year
problem
and
it's
reached
critical
mass.
X
They
were
in
denial,
they
refused
to
actually
say.
The
answer
is:
are
that
from
this
year
they
basically
said
the
answer
is:
are
there
which
means
eyeballs
are
on?
Are
there
now?
If
this
working
group
is
going
to
say
consciously,
we
have
two
streams,
I
feel
we're
heading
to
where
DNS,
op
and
v6
op
is,
which
is
we
need
to
meetings,
because
if
you
are
proposing
to
conduct
two
strands
of
activity
in
a
single
timeslot,
we
have
already
seen
from
the
depth
of
discussion.
It's
not
going
to
work.
There's
too
much
work
for
one
timeslot.
P
P
B
Thanks
before
we
got
too
far
down
this
path,
let
me
let
me
respond
a
little
bit
to
the
two
comments
that
been
made.
I
mean
yes,
thank
you
George
and
Rick
I
mean
all
of
that
is
true.
I
think
it's
important.
Let
me
make
following
observation
about
this
working
group
and
the
way
that
working
can
progress
and
and
what
I
like
about
this.
To
some
extent,
this
is
about
you
know,
milestone
management,
which
is
kind
of
an
administrative
task.
B
Nothing
prevents
the
working
group
from
quickly
going
through
documents
as
quickly
as
you
can,
and
you
know
if
you
are,
if
you're
really
interested
and
motivated
in
the
our
debt
stuff-
and
you
know
you
can
only
work
on
so
many
documents
at
a
time,
and
so
you
need
to
progress.
Those
set
of
documents
and
all
we're
saying
here,
is
giving
an
opportunity
to
have
a
milestone
which
has
milestones,
which
has
the
other
set
of
documents
on
it.
B
But
again,
the
success
of
any
particular
set
of
documents
is
dependent
on
work
party
members
who
want
to
progress
that
work
and
talk
it
and
have
that
discussion
on
the
mailing
list.
We'll
take
that
the
next
three
people
in
the
queue
and
then
I'll
just
jump
to
my
next
slide,
that
let's
let's
go
through
that
and.
Q
Let's
bring
over
I
think
that
the
two
work
streams
that
we
have
have
a
different,
completely
different
size
of
the
audience
and
and
the
problem
is
I
mean
look
at
EVP.
Epp
is
may
be
affecting
like
a
thousand
registries
these
times
these
days,
and
maybe
that
20
back-end
operators
and
maybe
let's
say
20,000.
Q
Worth
what
yeah?
Those
are
the
number
of
implementations,
yeah
and
well?
Are
there
I
would
say
in
the
next
coming
years,
I'm
sure
that
the
potential
audience
for
our
tip
is
at
least
in
the
hundreds
of
millions,
maybe
not
directly
but
indirectly,
and
there
is
going
to
be
a
lot
more
interest
on
that.
So
it
actually
makes
sense
that
we
spend
our
time
on
on
the
protocol
that
has
the
widest
and
most
intense
impact
on
the
Internet
infrastructure
as
a
whole
and
I
mean
EPP
sort
of
like
a
hidden
protocol.
Q
That's
like
the
protocol
that
airlines
use
to
travel
agencies
yeah
so
yeah.
You
know
it's
hard
and
if
you
say
the
second
point,
it's
like
quickly
going
through
documents.
You
know
that
speeds
typically
reduces
the
quality
of
the
output
or
tends
to
that's
the
8020
rule,
but
I
feel
we
are
there
already
anyways.
Y
Peter
containing,
like
that,
an
analogy
if
epp
is
the
protocol
that
airlines
use
in
talking
to
travel
agents,
then,
obviously
our
depth
is
a
protocol
that
airlines
used
to
transfer
the
passenger
name
record.
So
governments-
and
that
said
a
bit
concerned
about
the
high
potential
of
policy
laundering
that
is
again
in
front
of
the
working
group
in
terms
of
interpreting.
Y
What
is
mumbled
and
I
can
around
whether
or
not
our
DEP
is
the
solution
bear
in
mind
that
they
haven't
phrased
the
question
by
now,
not
picking
on
you
personally
George
that
happens
everywhere
and
combine
that
with
an
echoing
Alex
I.
Guess
combining
that
with
the
idea
to
quickly
go
through
these
documents,
without
having
in-depth
review
and
discussion
of
the
privacy
and
the
policy
aspects
of
these
things,
that
that
runs
the
risk
not
only
for
the
working
group
but
for
the
IDF
as
a
whole.
Y
So
that
is
not
a
nice
task
for
the
incoming
Area
Director,
but
may
be
a
challenging
one
and,
and
he
like
it.
So
to
that
extent,
yes,
this
is
the
hidden
protocol.
The
EPP
one
I
would
disagree
that
there's
a
hundred
million
of
consumers
for
our
dip,
it
better
not
be,
but
the
working
group
needs
to
have
a
broader
focus
and
it
should
not
just
be
dealt
with
by
that
small
group
of
travel
agents
that
talk
to
the
airline.
Thank
you.
O
So
anything
again,
so
I
want
to
take
george's
thought
experiment
a
little
bit
further.
If
we're
gonna
have
two
meetings,
maybe
we
should
have
to
work
oops,
one
of
the
things.
I
don't
do
EVP
work,
but
if
I
was
someone
who
did
I
wouldn't
want
it
to
get
starved
for
the
art
app
stuff.
If
we
do
believe
that
there's
gonna
be
an
avalanche
of
art
up
things
going
on,
then
it
may
make
sense
to
make
sure
that
the
epp
work
can
still
get
done.
B
So
yeah
Jimmy
n
here
and
thinking
about
all
of
this
all
very
good
points
and
and
I
think
that
it's
interesting
to
think
about
what
the
right
way
is
to
manage
our
work
and
how
to
move
it
forward.
I'm
I'm
personally,
as
chair
not
inclined
to
to
separate
working
groups
only
because,
at
least
in
my
mind,
there's
a
pretty
strong
relationship
between
these
two
sets
of
work,
items
and
I
feel
like
you
know,
gonna
have
two
working
groups
or
we're
gonna.
B
Have
everybody
the
same
set
of
people
in
both
groups
to
some
extent
and
I
I,
don't
know
I
mean
I
could
be
wrong
there,
but
that's
just
something
which
goes
to
my
mind.
I
I
worry
that
they're
pretty
well
related.
Let
me
just
get
to
the
next
slide
here
and
make
this
a
little
more
concrete
in
terms
of
what
we
are
gonna
suggest
here.
We're
gonna
try
to
stay
focused
on
at
most
five
milestones
at
a
time.
B
Okay,
so
we
need
to
pick
five
tasks
that
were
actually
committed
to
producing
by
a
deadline,
but
I
do
think
it's
important
that
you
know
to
the
extent
to
our
related
documents.
That
doesn't
mean
that
we
can't
be
talking
about
other
things
on
the
mailing
list
and
other
things
can't
be
visible
and
there
this
is
really
about.
How
do
we
focus
our
work?
Right?
I
mean
it's
just
just
project
management,
we're
all
used
to
that,
and
that's
what
we
do.
B
So
we
pick
the
five
things
that
are
the
most
important
to
us
and
we
just
try
to
move
them
along,
and
so
you
know
the
specific
proposal
was
to
think
of
this.
In
terms
of,
if
we're
going
to
have
five
milestones,
you
know,
maybe
we
split
them
up
in
some
way
so
that
we
at
least
allow
a
path
so
that
there's
documents
on
each
side
that
can
be
worked
on
concurrently
by
a
group
of
people.
The
obvious
you
know
easy
split
is
two
milestones
for
streams.
B
Since
we
got
five
and
then
you
just
have
a
fifth
one
that
you
assign
as
appropriate-
and
so
you
know
that
just
sort
of
if
you
follow
that
sort
of
easy
logic,
you
end
up
with
something
which
looks
like
this
in
terms
of
milestone
priorities,
it
turns
out
the
login.
Security
is
already
on
the
registry
registrar
side.
So,
while
we're
talking
about
doing
here
is
substituting
one
of
these
other
two
documents,
this
is
taken
right
at
the
poll
results
on
December.
So
we
can
revisit
that
if
we
want
to.
B
But
those
were
the
next
two
documents,
the
domain
name,
registration,
data
mapping
and
the
data
escrow
specification
were
the
next
two
documents
out
of
the
poll
results
from
December
and
that's
why
they
got
there
and
the
our
DAP
ones
that
we
had.
You
know
those
are
the
three
that
we
had
if
we
follow
sort
of
the
plan
that
we're
talking
that
we're
proposing
here
and
one
of
these
would
have
to
be
put
and
and
sort
of
delayed.
B
While
we
focused
on
two
of
them,
two
of
those
three,
the
partial
response,
reverse
search
and
sorting
and
paging.
So
we'd
have
to
pick
two
of
them
to
focus
on
and
get
one
of
them
done
before.
We
focused
on
on
that
third
one
as
well
as
starting
to
pick
through
the
remaining.
You
know,
15
documents
that
we
had
and
our
backlog
here
so.
B
Yeah
any
other
discussion
or
comments
about
any
of
this.
Anybody
wouldn't
want
to
offer
something
we
resisted.
I
will
tell
you
that,
although
we
had
thought
before
we
would
well
somebody
do
you
want
to
get
up
to
the
mic.
That's
fine!
We
resisted
putting
calendar
outputs
assertion
with
these
things,
because
we
figured
choosing
a
deadline
for
when
we
want
to
get
them
done
by
is
a
lot
easier
than
then
having
a
discussion
about
whether
this
is
a
proper
way
to
manage
the
work
in
the
working
group.
B
C
C
I
mean
if
that's
there,
it
may
be
possible
to
make
progress.
You
know
on
these
two
streams
at
different
paces
and
part
of
the
reason
I'm
asking
is
like,
as
I
said
before,
that
federated
authentication
document
it's
going
to
be
in
the
queue
for
a
little
while
and
not
that
it's
going
to
be
there
because
of
a
lack
of
work.
C
I
think
in
some
ways
there
going
to
be
some
unanswered
questions,
and
so
you
know
the
editor
and
the
working
group
either
have
to
admit
that
we're
not
going
to
be
able
to
get
it
done
until
we
have
answers
to
certain
questions
or
we
have
to
come
up
with
a
mechanism
that
allows
the
answers
to
those
questions
to
be
accommodated
at
a
later
date
anyway.
So
so
I
don't
want
necessarily
that
document
blocking
others
just
because
we
have
an
arbitrary
restriction
on
X
number
of
our
def
documents.
B
Let
me
make
two
observations:
I
guess
and
take
your
question
on
board,
but
just
make
two
observations.
Rather
than
respond
directly.
You
know
this
working
group
even
over
our
years
of
existence,
and
we
spend
a
couple
of
years
as
the
EPB
extensions
working
group
before
we
became
reg
X
and
sort
of
combine
the
two
we'll
put
them
together.
We
tend
to
operate
very
much
in
fits
and
spurts
ebbs
and
flows.
So
there's
not
a
stream
of
success.
We
are
very
much
driven
by
IETF
meetings.
You
know
that
the
deadlines
there
a
lot.
B
Groups
do
that
in
the
IETF,
so
we're
not
special
in
that
regard,
but
it's
important
to
keep
in
mind.
You
know
how
work
progresses
so
there's
not
just
external
factors
as
what
Scott
is
referring
to.
You
know
that
to
really
be
final
about
the
technical
proposal,
we
really
are
waiting
to
see
what
policy
framework
is
going
to
be
out
there
that
we're
really
trying
to
solve
for
and
provide
a
solution
to,
and
you
know
so,
you're
right.
That's
taking
up
a
milestone
slot.
So
that's
one
thing.
B
The
second
observation
I
would
make,
is
you
know,
and
maybe
I'll
make
this
observation
and
then
I'll?
Look
through
our
I
see
that
Barry
came
into
the
room,
and
so
maybe
he
can
respond
to
this
at
some
point
when
it's
convenient
in
the
process,
I,
don't
think
that
there's
any
harm
in
having
working
group
documents
and
having
to
be
adopted
by
the
working
group
and
they're
just
there
and
we
don't
have
a
committed
milestone
for
them
because
we're
not
ready
to
make
a
deadline.
So
you
know
maybe
what
the
thing
to
do
is.
B
Is
we
pull
back
the
the
federated
authentication
from
having
a
deadline
and
and
still
keep
us
with?
You
know
with
five
slots,
but
now
we
have
yet
another
slot
to
assign
to
something,
and
actually
we
should
items
for
milestones
that
we
know
we
can
actually
commit
to
and
we
have
a
deadline
we
can
meet
other
things
can
simply
be
there
in
our
backlog,
and
you
know
under
discussion
on
the
mailing
list,
waiting
for
when
we're
ready
to
commit
them
to
a
deadline.
B
Then
we
can
sort
of
evaluate
that
as
we
go
along
in
all
of
the
space.
Maybe
that's
the
right
way
to
do
it.
The
the
number
of
five
work
items
goes
back.
This
is
the
point
I
didn't
make
in
my
first
point.
The
reason
why
there's
only
five
milestones
is
because,
having
more
than
that
is
really
just
a
lot
to
manage.
B
If
you
think
about
this
working
group,
when
we
converted
to
being
reg
X
from
a
PBX
we
took
on
I,
it
was
was
10
or
11
milestones
that
we
put
out
there
and
it
really
we
spent
years
just
sort
of
getting
that
under
control
and
committing
it's
tough
to
focus
when
you
have
too
many
things.
So,
there's
there's
strong
push
and
having
talked
to
multiple
area
directors
over
the
years
to
keep
that
number
small.
B
So
we
have
to
find
a
different
way
inside
the
working
group
to
manage
that
five
and
I'm
sorry
I
talked
a
lot
on
the
we
are
taking
away
from
our
new
work
item.
Discussion.
I
just
want
to
call
that
out.
But
now
this
is
an
important
discussion.
I
don't
want
to
stop
this
discussion.
This
stuff
is
really
important,
so
so
I.
O
Just
want
to
say,
I
agree
with
what
Scott
said,
and
it
kind
of
seems
like
we're,
starting
out
with
our
tap
already
constrained
right
the,
and
you
would
addressed
a
lot
of
this.
The
I
just
want
to
note
that
I've
talked
to
people
who
said
hey.
I
would
like
to
do
something
with
our
tap,
but
I'm
not
going
to
take
it
to
the
IETF,
because
it's
just
never
gonna
get
done
and
that's
a
real
perception.
So
we
do
need
to
address
it.
O
X
You
George
Michelson,
ap,
Nick,
I,
think
for
privacy.
Stuff
is
very
important
and
I,
don't
think
it
is
going
to
be
resolved
by
having
privacy
sections
included
in
individual
Docs
I
think
we
are
going
to
need
an
overarching
doc.
That
says
there
is
a
general
community
expectation,
stupid
things
don't
happen,
and
these
are
guiding
principles
and
I.
Don't
think
we'll
be
able
to
close
on
it
in
this
working
group.
I
think
is
going
to
go
way
up
because
that
reverse
search
function
is
absolutely
vital
for
law
enforcement.
X
It's
unavoidable
that
they
are
going
to
say,
I
need
to
see
every
record.
This
stolen
account
has
potentially
interfered
with
because
the
password
was
broken
and
that
collides
absolutely
head-to-head
with
Stefan's
point.
This
is
a
massive
breach
of
privacy.
If
you
routinely
allow
people
to
do
that
kind
of
reverse
search,
but
the
problem
is
real.
Both
sides
are
real
and
we
will
need
a
document
and
we
will
need
upstairs
conversations
about
what
we
really
want
to
do
here.
So
I
think
there's
going
to
be
a
big
hole
here.
B
B
B
And
one
last
comment
down
before
Barry
sums
it
up
for
us
here.
It
tells
us
what
we
did
the
way
we
were
really
supposed
to
work.
This
I
I
think
that
we
do
actually
the
question
we
have
to
ask
ourselves
about
documents
that
are
milestones
is
you're
right
when
we
have
very
broad
questions
that
you
know
demand
a
lot
of
discussion,
maybe
maybe
we
can't
commit
to
milestone
yet,
and
we
have
to
figure
out
how
to
have
more
discussion
about
it
and
and
defer.
J
B
Know
that
commitment
to
to
closing
on
it.
You
know
that
I
mean
that's
one
way
to
interpret
that
that
question
about
privacy.
Maybe
it
can't
be
a
document,
that's
on
our
milestone
list,
yet
because
there
are
too
many
open
questions
at
the
moment
about
what
we
need
to
get
to.
So
thank
you
over
to
Barry.
Please
now.
K
This
is
Barry,
so
there
are
a
few
points
here
regarding
to
what
what
Scott
said.
Well.
First,
the
overall
I
I
think
it
would
be
a
shame
to
Reese
Plitt.
The
working
group
I
I
will
not
object
to
that.
If
that's,
what
the
working
group
decides
is
the
right
thing,
but
I
think
these
guys
up
front
are
capable
of
managing
the
working
group
as
it
is
and
we
can
adjust
how
that
works.
They
can
adjust
how
that
works.
I
can
negotiate
with
you
guys
about
how
many
milestones
are
appropriate.
K
K
You're
gonna
be
working
on
at
some
point,
and
then
you
have
the
ones
that
you're
actually
actively
discussing,
and
then
you
have
the
ones
that
you've
committed
to
a
date
when
you're
going
to
get
them
done,
and
you
know
that
shifting
things
around
in
those
other
two
categories
can
help.
You
work
this
out
to
what
George
said.
I
think.
If
that
document
is
really
that
important
to
get
done,
then
I
think
it
should
be
a
milestone
should
be
put
on
it
at
some
point
of
we're.
K
K
The
real
the
reality
is
that
any
working
group
only
has
a
limited
capacity
and
I.
You
know
I
think
if
we
split
this
working
group
you're
going
to
get
two
separate
working
groups
that
have
less
capacity
so
I
know
I,
don't
think
that's
going
to
help
the
situation
and
I
think
that's
all
I
had
to
say
about
it
that
let's
discuss
the
chairs
and
I,
how
many
milestones
you
need
and
how
we
want
to
gate
things.
K
B
And
so
thank
you
for
that
Berrien
and
we
can.
We
can
bring
this
to
to
the
mailing
list
and
and
figure
out
if
we
we
need
a
different
number,
because
we
have
different
documents.
I
mean
frankly
at
one
level,
since
this
then
becomes
a
natural
set.
Based
on
on
the
poll
that
we
had
before,
we
can
just
tell
ourselves
well,
heck
7
is
the
right
number,
we
add
two
more.
B
Then
we
get
exactly
what
we
had
before
and
we
give
fairness
to
to
the
registry
and
registrar
options
and
let
them
continue
to
work
on
things,
and
that
might
be
the
answer.
But
you
know
people
can
take
some
time
to
think
about
that.
Please
say
something
on
the
mailing
list
or
if
you
want
to
come
talk
to
us
separately
and
privacy
privately,
you
know
please,
please
do
we
really
are
trying
to
figure
out
what
the
best
way
is
to
move
work
forward
and
there
are
competing
priorities.
I
guess
is
what
it
comes
down
to.
B
This
is
all
just
project
management
in
standards,
development,
I,
suppose
yeah.
So
we
are
well
over
time
here.
In
theory,
we
have
35
minutes
of
presentations
allotted
and
we're
clearly
not
going
to
be
up.
We
only
have
20
minutes
left
so
we're
clearly
up
15
minutes
under
time
here.
But
let's
move
to
our.
B
New
work,
oh
yeah,
well,
I
had
a
I
had
a
blank
slide
there
for
draft
milestones
for
that
discussion,
hopefully,
to
repeat
the
comment
about
not
really
putting
calendar
on
things,
but,
okay,
so
Newark.
We
have
four
items
here
for
Newark,
and
so
these
are
just
offering
options
for
potential
documents
that
we
might
want
to
adopt.
So
this
is
basically
adding
to
the
21
documents
that
we
had,
and
you
know
maybe
having
a
bigger
backlog,
but
each
of
these
folks,
maybe
if
Tom
Harrison,
is
in
here
somewhere.
You
want
to
come.
B
We
can
can
speed
this
up.
This
is
more
of
a
introduction
to
some
topics,
and
maybe,
since
we
really
need
to
focus
on
what
we
know,
we
want
to
do
unless
you
have
an
interest
in
wanting
to
move
one
of
these
things
to
on
our
priority
list.
Instead
of
just
onto
our
back
glogg,
we
can
save
most
of
the
discussion
for
the
mailing
list,
so
go
ahead.
Tom
thanks.
Z
This
one
I
take
the
five
minutes:
okay,
so
at
mirroring
it's
a
protocol
for
retrieving
all
of
the
data
from
an
app
server
and
for
keeping
that
data
up
to
date
over
time.
There
are
three
use
cases
for
this
work.
The
first
one
is
when
the
overhead
for
querying
the
remote
server
is
too
high.
The
second
one
is
when
the
client
wants
to
do
some
sort
of
whole
data
set
analysis
and
the
third
one
is
when
the
client
wants
to
republish
the
service
data
in
its
own
right.
Z
This
third
one
is
the
important
one
for
APNIC.
At
the
moment,
we
have
national
IP
registries
in
our
region
that
send
us
Whois
data,
but
they
only
send
us
english-language
Whois
data
because
of
limitations
in
our
who
is
so.
If
we
can
switch
to
using
adapt,
then
they
can
send
us
English
and
local
language.
We
can
serve
that
from
our
server,
and
that
makes
it
more
useful
for
clients
in
that
region.
Z
The
protocol
defines
three
file
formats.
The
first
one
is
the
update
notification
file.
This
is
the
entry
point
for
a
client
and
it
in
turn
contains
links
to
snapshot
and
a
series
of
Delta
files.
The
snapshot
contains
all
of
the
data
from
the
server
as
at
the
time
of
generation,
and
the
deltas
contain
the
changes
that
have
happened
since
the
snapshot
was
generated
so
walking
through
this
from
the
clients
perspective,
the
client
fetches
the
update
notification
file.
Z
You
can
see
here
that
there's
just
a
snapshot,
so
the
client
fetches,
the
snapshot
takes
the
objects
out
of
it,
since
it's
local
state
up
accordingly
later
on.
Something
else
causes
some
updates
to
happen
to
the
server
and
the
server
generates
a
delta
file.
So
when
the
client
comes
back,
it
sees
that
Delta
file,
fetches
it
and
updates
its
local
state.
Z
Z
Z
U
From
both
Maya
I'm,
the
one
who
is
very
true
about
privacy
consideration,
because,
unlike
a
PGI
that
you
mentioned
a
lot,
this
one
is
much
more
sensitive
data.
But
I
have
another
question:
is
this
someone
who
expressed
some
interest
about
this
ID
because
I'm,
not
convinced
by
the
use
case
on
in
my
case,
for
the
minimal
history
I'm
certain
that
our
legal
department
would
refuse
flat-out
to
export
the
LDAP
complete
bulk
depth
data
to
outside?
So
other
people
who
are
ready
to
export
the
entire
database?
U
Z
We
have
national
registries,
so
you
already
give
us
their
data
in
who
is
format.
So
if
we
can
get
that
font-
and
so
that's
pretty
much
it
yeah,
like
that's
the
immediate
use
case,
we
also
do
some
export
stuff
to
clients
who
are
willing
to
an
acceptable
use
policy
agreement.
So
we
could
also
use
that
in
that
case,
as
well.
X
George
Michaelson,
it
is
not
actually
necessarily
strictly
true
that
what
is
exported
is
one
to
one
the
same
as
what
is
in
the
prime
service.
So
in
our
current
who
is
mirroring,
we
explicitly
exclude
certain
fields
in
order
to
protect
information,
we
don't,
for
instance,
pass
script
strings,
so
the
mechanism
is
about
keeping
in
sync
with
a
record
as
a
logical
entity,
it
doesn't
say
is
exactly
the
same
as
what
is
held.
That's
one
part.
The
second
part
is
that
mechanisms
like
this
are
necessary.
X
If
you
have
a
contractual
obligation
for
escrow,
so
you
could
imagine
a
gTLD
having
an
R
DEP
requirement
and
then
also
having
to
supply
us
grow
data
to
some
location
under
contract.
This
is
a
mechanism
that
would
permit
that
it's
not
intended
that
a
client
is
using
this
query
and
republish,
but
it
is
the
mechanism
to
guarantee
public
data
is
available
elsewhere.
U
B
AA
B
AA
G
AA
Registries
do
not
have
registrant
data,
and
the
registrar's
I
have
so
are
that
query
to
a
thin
registry
we'd
have
to
provide
a
link
in
a
sensor
to
a
registrar
earth,
app
server.
So
the
question
here
is
how
do
I
find
the
our
dev
server
URL
of
the
registrar,
so
you
we
need
a
mapping
of
our
registrar,
ID,
2-yard,
app
server
location.
AA
AA
So
the
question
here
is:
we
could
use
that
number
as
the
entry
for
Indy,
for
example
the
air
that
Jason
file
that
says
bridge
for
ID,
here's,
the
server
location,
URL,
then
the
question
is:
do
we
have
additional
registrar's
that
do
not
fit
into
this
list,
so
that
use
case
would
be
either
thin
field,
ctod
registrar,
running
our
that
for
that
in
ccTLD
and
not
selling
an
EEG
TLD.
So
that
was
actually
one
question
I
sent
to
the
yard
app
I
can
hire
that
pilot
working
group
is
this
use
case
really
exists.
W
AA
AA
AA
AA
Our
depth,
server,
URL
and
would
be
obviously
in
JSON,
as
the
other
bootstrap
registries
looks
like
comments
received
so
far
and
deep.
So
why
not
use
object?
Tag
are
that
thing
are
see
frankly,
I
haven't
looked
at
yet
my
my
recollection
of
this
draft
was
to
manage
the
air
in
the
different
IR.
You
know
that
far
so
I
was
like
that's
not
the
case,
so
we'll
sue,
James,
different
JSON
format,
I
think
we're
not
yet
there.
AA
O
AA
O
O
L
Jim
rules
from
Verisign,
so
this
actual
problem
came
up
before
I
can
volunteer
to
update
their
repository
for
registrar's
to
include
the
are
DAP
URL
which,
in
my
opinion,
actually
solves
the
problem,
and
this
is
really
not
just
forth
in
registries
by
the
way
this
is
for
all
registries
yeah.
The
point
is
I
think
if
there
are
other
repositories
of
registrar
information,
then
yeah
I
think
this
would
be,
but
I
don't
see
that
at
this
point
so.
O
AA
O
Anything
you
just
today
that
I
am
is
updating
another
registry
with
hard
hat
URLs
yeah
that
I
really
don't
like
that
either
because
as
an
R
type,
implementer
I
want
to
go
to
one
place
in
the
eye
in
a
space
which
is
clearly
the
r
type
area.
So
if
they're
putting
art
up,
you
are
ELLs
and
then
we've
been
instructed
by
us
to
do.
B
I
AA
G
AA
O
B
AB
Is
that
we're
in
the
process
of
bootstrapping
the
whole
system
now
and
every
registrar
has
to
tell
every
registry
what
its
base
URL
is
and
that
you,
if
you
multiply
number
which
draws
by
number
of
retrieves
you
end
up
with
millions
of
emails,
going
backwards
and
forwards.
So
so
the
need
was
well.
That's
that's.
How
can
we
simplify
this?
I
am
Ayanna
maintains
a
list
of
ICANN
accredited
registrar,
IDs,
it's
the
actual
Ayane
maintains
it,
but
it's
actually
populated
from
I.
AB
AB
N
N
AA
X
B
O
Here,
I
want
to
try
to
save
you
a
little
bit
of
time.
The
there's
been
discussion
about
the
j-card
issues.
This
is
necessarily
my
discussion.
That's
why
there
are
no
slides
on
this
and
I'm
gonna
send
the
notes.
I
have
because
I've
been
talking
with
various
people
to
the
mailing
list,
so
we
can
have
a
discussion
there.
I
think
what
I
would
like
to
get
out
of
this
is
how
many
people
actually
think
we
need
to
do
something
about
J
card.
O
O
B
Q
Thanks
for
a
ten
minutes,
I
think
I
need
just
like
30
seconds.
So
I
floated
the
idea
that
we
should
look
at
whether
we
can
do
anything
around
the
standardization
of
depending
on
the
registry
is
called
security,
log
registry
log,
whatever
additional
mechanism
that
prevent
like
modification
of
the
allocation
date
of
the
domain
name
and
the
most
important
information
comes
now
yeah
we're
going
to
have
a
side
meeting
on
Wednesday
at
2:00
p.m.
in
room
Paris.
Q
Q
B
O
M
Q
Q
I
thought
I
would,
if
you
have
something
in
your
registry
system
that
looks
like
security,
lock
or
registry
lock.
It
would
really
be
nice
if
you
could
like
prepare
to
speak
about
it
in
two
minutes.
What
it
is
yeah,
so
I
plan
to
do
it
to
the
table
all
what
are
you
doing?
What's
your
level
of
security
and
after
that,
I'm
gonna
write
the
summary
and
see
where
we
can
go
from
there.
So
that's
my
thanks.
B
C
Sure,
thank
you
Scott
Hollenbeck
yeah.
As
the
slide
says,
we
are
doing
another
registration
operations
workshop
in
Bangkok
on
9
May.
If
you're
not
familiar
with
what
this
series
is,
we
really
do
like
to
focus
on
the
work
part
here
of
workshop.
This
is
not
intended
to
be
presentations
where
you're
just
kind
of
sitting
there
getting
read
we're
looking
for
proposals
for
people
who
have
topics
that
need
some
real
discussion,
and
if
you
are,
for
example,
a
gTLD
registry
or
registrar,
you
are
at
least
you
should
be
in
the
midst
of
implementing
our
DAP
right.
C
Now,
if
you
find
things
in
the
specs,
you
don't
like
guess
what
you
are
a
good
candidate
for
submitting
a
proposal
for
a
discussion
or
a
panel
right.
So
please,
if
you
know
you're,
going
to
be
in
Bangkok
for
one
of
those
other
events,
you've
got
some
good
things
to
think
about.
We
do
have
a
call
for
proposals
out.
I
would
encourage
you
to
get
that
in
ASAP.
I
know
the
people
who
are
coordinating
this
and
I
can
tell
you
right
now.
We
do
have
room
for
more
presentations,
I'm,
sorry,
discussion
slots.
Thank.
B
You
may
9th
actually
fits
precisely
it's
the
afternoon
of
the
GDD
industry
summit.
It's
the
last
day
of
that
the
afternoon.
That's
where
this
is
and
then
the
the
DNS
symposium
is
the
next
day.
So
that's
where
it
may
9th
fits
in
that
overall
co-located
with
last
chance
for
any
other
business.
Anybody
not
seeing
any
hands
go
up.
No
one
is
standing.
Thank
you
very
much.
Everyone
appreciate
your
being
here,
and
so
we
return
Oh
blue
sheets.
Of
course,
anyone
once
to
get
the
blue
sheets
they're
up
here
make
sure
your
names
on
it.