►
From YouTube: IETF110-REGEXT-20210309-1600
Description
REGEXT meeting session at IETF110
2021/03/09 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
It
did
and
just
just
capture
key
points.
You
don't
have
to
write
a
long-winded
summary
or
anything.
A
So
this
is
welcome
everyone,
as
we
are
at
the
top
of
the
appointed
hour
here,
welcome
to
antwandershorn.
I
am
james
galvin.
We
are
your
co-chair
for
registration
extensions
and
this
is
our
virtual,
prague
meeting.
Shame
we
can't
be
in
that
actual
location,
but
we
will
take
what
we
can
get.
A
A
A
D
A
This
is
kind
of
a
slow,
rolling
working
group
in
general,
and
you
know
it's
just
useful
to
tell
people
and
remind
people
that
work
moves
when
when
people
progress
it,
if
you're
interested
in
something
moving
along,
then
you
know
you.
A
You
have
to
say
that
and
and
mention
that
and
drive
that
on
the
mailing
list,
and
sometimes
you
also
have
to
remind
your
your
your
chairs
a
couple
of
times
over
to
move
some
things
forward,
but
we'll
we'll
take
care
of
that,
and
I
see
that
alex
has
his
hand
up
in
the
queue
we'll
break
for
a
moment
and
let
alex
speak
up
go
ahead.
Please.
A
C
I
plan
to
use
the
the
kodi
md.
Is
that
what
you
mean
by
insert,
or
do
you
do
you
want
me
to
do
the
minutes
anywhere
else?
Yes,
it's
golden
d.
A
Yeah
yeah,
it's
code,
md,
I'm
sorry,
I've
just
been
misspeaking
you're
right
but
yeah
with
the
the
link
at
the
top
of
the
the
page
there.
So
thanks
very
much
for
that.
The
last
thing
welcome
in
introductions.
Is
we
always
like
to
talk
about
document
shepherds?
You
know
we
really
are
trying
to
make
sure
that
we
have
a
document
shepard
and
we've
had
actually
quite
a
few.
So
that's
a
good
thing.
You
know.
A
E
A
Okay,
so
next
on
our
agenda,
published
works,
we've
had
a
banner
year
in
2020,
so
we
have
three
rfcs
that
have
been
published
since
the
last
time
we
met
in
november
data
escrow,
the
rdap
query,
parameters
got
updated
and
the
partial
well
for
sorting
and
paging.
I'm
sorry
query,
parameters
for
sorting
and
paging
and
partial
response.
A
Those
are
extensions
to
rdap
and
they've
both
been
published.
So
that's
a
good
thing,
all
three
of
those
and
then
moving
right
along
here
we
have
our
status
of
existing
work.
Again,
we've
kind
of
had
a
a
banner
year
in
2020.
We
have
quite
a
number
of
documents
that
are
somewhere
along
the
way
in
the
publication
cycle,
and
so
that's
been
quite
a
quite
a
year
of
success
for
us.
A
I
think
this
is
our
our
best
year
in
terms
of
documents
moving
forward,
so
the
data
escrow,
the
object's
mapping
document
the
data
escrow
document
has
already
been
published.
The
object's
mapping
document
is
imminent.
It's
on
its
way.
We
of
course
have
updated,
7482
and
7483,
which
are
the
rdap
query
and
response
documents.
A
They
are
about
to
be
upgraded
to
full
internet
standards.
Those
are
also
imminent,
and
it's
worth
noting
that
7480
and
7481
are
also
going
to
be
elevated
to
internet
standards,
but
without
errata
in
their
case.
So
in
that
case,
it's
just
a
a
process
step
that
the
iesg
goes
through
to
take
those
documents,
as
is
to
upgrade
them
and
elevate
them,
and
jim
reed
get
your
hand
up
guys.
Please.
F
Hi,
jim
I'm
gonna
put
you
on
the
spot
here.
What's
your
best
guess,
when
these
documents
will
escape
the
rfc
editors
queue
or
is
that
a
stupid
question.
E
A
E
I
joined
it
just
the
right
time.
It
is
definitely
not
a
stupid
question,
but
it's
a
question.
That's
very
difficult
to
answer.
However,
the
rfc
editor
since
the
publication
of
cluster
238
has
been
turning
things
around
reasonably
quickly.
So
I
don't
know
I
guess
I'm
guessing
probably
within
where
are
we
we're
in
this?
Probably
sometime
mid
april
is
my
guess,
but
it
could
be
sooner
and
it
could
be
longer.
It's
really
hard
to
tell.
A
Yeah
thanks
jim
and
thanks
barry
for
that
question
and
again
7480
and
7481,
which
are
part
of
the
rdap
series
of
documents
they're
just
going
to
elevate
without
errada.
So
that's
just
the
status
change,
but
we
do
do
go
through
a
process
in
the
ietf
to
reflect
that.
So
everyone
knows
it
and
then,
as
we
move
up
here,
oh
I'll
also
just
mention
you'll
see
later.
7484
is
a
new
document
for
us.
A
A
A
All
in
the
publication
cycle,
and
hopefully
they'll
all
move
along
fairly
smartly,
but
you
know
kudos
to
us.
You
know
thank
you
to
the
working
group.
It's
just
a
bit
of
process
that's
going
on,
but
I
think
I
expect
all
of
these
things
to
proceed
and
that's
just
a
good
reflection
on
us.
We're
able
to
move
along
so
much
work
and
so
many
things,
but
as
we
see
we're
gonna,
we
have
a
number
of
things
that
are
also
still
on
our
agenda
to
move
along
and
get
into.
A
So
if
there
are
no
questions
about
those
we'll
jump
into
a
quick
look
at
some
existing
work
and
antoine,
were
you
going
to
pick
up
here
or
did
you
want
me
to
do
this
next?
One
too.
B
So
next,
so
we
have
four
documents
which
don't
have
a
presentation
for
this
time.
We
have
regis
registry
maintenance
and
that
basically
has
been
in
working
group
last
call
already,
but
it
was
taken
back
after
working
with
lascaux,
because
there
was
two
narrow
consensus.
We
still
had
quite
some
comments
during
working
with
last,
and
actually
we
didn't
have
any
people
that
were
actively
responding,
that
they
would
that
they
they
approved
this
document.
B
So
I
don't
know
if
any
any
of
the
authors
want
to
have
a
comment
on
this
on
what
their
actions
are
going
to
be.
Let's
see
if
we
have.
A
So
before
you
call
on
jody,
I
should
probably
jump
in
in
fairness.
Jody
is
one
of
the
authors
and
he
was
going
to
speak,
but
I'll
I'll
spare.
A
A
The
the
document
shepard
for
this
document-
and
this
is
a
work
item
for
for
antoine-
and
I
you
know
I
I
have
to
review
the
the
issue
that's
going
on
here
and
then
you
know
as
part
of
being
a
document
shepard
and
provide.
C
A
Comments
to
antoine,
in
particular,
since
he's
going
to
be
the
chair,
that's
guiding
this
work,
so
this
is
not
on
the
authors.
This
is
on
me
as
document
shepard,
not
having
caught
up
with
providing
a
summary
here
that
we
can
then
work
with
and
figure
out
what
to
do
with.
A
I
mean
so
antoine's
assessment
they
are
about
not
really
having
full
consensus
in
our
working
group
is
appropriate
and
we
just
haven't
figured
out
what
we
want
to
do
about
that
yet
and
to
make
a
proposal
back
to
the
working
group
to
deal
with
it.
So
that's
enough,
and
it's
more
precisely
on
on
me
as
document
shepard.
Yes,
I.
B
I
was,
I
was
more
trying
to
you
know,
look
for.
You
know
what
what
can
we
do
to
get
this
document
progressed?
It's
it's
not
only
handling
the
comments
that
were
made
during
working
with
last
call,
but
also,
I
think
we
should
be
looking
for
support
before
we
put
something
into
working
group
last
call.
There
must
be
some
sort
of
a
sense
that
people
have.
C
B
G
Hi,
can
you
guys
hear
me
all
right
yeah?
We
can
hear
you
all
right.
I.
I
can't
hear
anybody
right
now,
but
as
long
as
you
can
hear
me,
we've
been
working
extensively
with
jim
gould
on
this
and
really
appreciate
his
feedback.
Tobias
has
updated
the
document
we've.
I
think
we
have
addressed
all
of
jim's
concerns
with
the
document
and
we
feel
it's.
G
It's
probably
should
be
going
to
working
group
last
call
as
we've
we've
we've
addressed
all
the
the
concerns
that
jim
has
with
it,
except
for
one
the
version
number,
which
will
update
the
version
number
one
we
put
it
in
in
last,
call
that
that's
where
we're
at
with
this
right
now,
thanks.
B
Yeah
yeah,
so
what
I
want
to
thank
you,
jodi.
What
I
wanted
to
highlight
is
also
for
people
in
the
working
group.
The
you
know
we
need
support
others
than
the
alters
during
a
working
group.
Last
call.
So
if
you
see
that
the
document
is
is
nearing
working
group
last
call
please
review
it
and
at
least
have
a
positive
comment
during
working
glass
call.
So
we
can
declare
consensus,
but
if
it's
only
you
know
one
or
two
people
responding
to
a
working
group
last
call.
B
We
cannot
call
out
consensus
that
everybody
has
read
the
documents.
I
Oh
sorry
about
that
yeah
yeah.
I
just
want
to
mirror
what
jody
had
said.
I
wanted
to
thank
the
authors
for
working
through
my
long
list
of
feedback
and
at
this
point
I
feel
like
they've
with
the
latest
draft
have
addressed
my
feedback.
B
A
Just
a
slow
roll.
You
know
we
submitted
a
revised
document
with
some
minor
edits,
but
we
haven't
pressed
on
it
on
the
mailing
list.
So
it's
it's
due
to
get
some
discussion
going
again
on
the
mailing
list
and
we'll
we'll
take
it
to
there
to
do
it.
B
Okay,
so
no
real
progress
or
upgrades
good,
then
the
open
id
document
now
that's
been
in
our
queue
for
a
long
time
and
of
course,
we
know
that
we're
waiting
for
some
decisions
being
taken
there
in
icann
to
see
if
we
need
to
adjust
the
technical
specifications.
Here
we
will
be
talking
about
milestones
at
the
end
of
this
meeting,
and
this
has
been
on
our
milestones
for
quite
a
long
time
and
we
we
are
going
to
move
it
along
again,
but
just
to
give
everybody
a
chance
to
talk
about
this
document.
J
J
You
know
when
I
get
some
free
time
so
there's
at
least
one
edit
that
I
want
to
make,
but
but
other
than
you
know
keeping
it
alive
until
we
see
what
happens
you
know
over
and
I
can
land
and
whether
or
not
that
has
any
impacts
on
the
draft.
I
don't
currently
have
anything
else
queued
up,
so
we
can
continue
to
let
this
one
simmer.
You
know
for
as
long
as
we
need
to
and
as
long
as
we're
comfortable
keeping
it
simmering.
B
Yes,
that
that
is,
of
course,
an
issue
scott,
because
yeah
it
takes
up,
of
course,
some
slots
in
the
working
group,
even
though
you
know
we
don't
take
any
time
or
we
don't
lose
any
time
on
it.
But
it's
something
that
I
think
in
one
or
two
years
time.
Nobody
will
remember
anymore
what
the
status
of
the
document
is.
So
that's
why
I'm
calling
it
out
every
time
that
that
we
meet
alex?
You
have
other
comments.
C
Just
just
a
very
brief
comment:
I'm
working
on
an
rdub
server
that
actually
uses
jbts
to
authenticate
users.
It's
not
a
full
open
id
connect
implementation,
but
at
least
this
understands
the
the
the
the
authentication
header.
So
that's
maybe
something
where
I
hopefully
will
have
time
to
review
that
that
draft
again
and
provide
some
feedback
squad,
because
it's
obviously
really
related.
B
Then
the
next
document
is
a
document
that
we
recently
adopted,
which
is
a
js
contact.
This
document
used
to
be
called
jcart
depreciation.
Now,
during
the
adoption
of
this
document,
we
thought
that
would
not
be
very
much
appropriate.
It
would
be
appropriate
to
use
this
document
to
define
js
contact
in
rdap,
but
not
mandate,
depreciation
of
jcart
because
it
has
been
implemented
already,
and
I
think
we
need
to
think
a
little
bit
more
about
that.
B
K
Saying
that
we
are
just
we,
we
are
just
waiting
for
the
outcome
of
the
extended
call
for
working
group
adoption
to
move
the
document
forward.
I
I
know
that
there
are.
There
is
some
interests
from
alex
my
roofer
and
yazda
to
contribute
to
this
document.
K
J
I
want
scott
holland
back
yeah.
I
think
I'm
one
of
the
people.
That
was
probably
the
reason
for
why
we
needed
to
do
a
second.
You
know
adoption
call
here,
and
I
think
we've
gotten
past
that
right,
but
my
concern
was
that
if
we
deprecate
j
card
right,
what
that
implies
is
it
goes
away
and
everyone
who's
already
implemented,
invested
the
time
and
effort
and
getting
it
working
you
know,
might
find
themselves
having
to
throw
out
something.
That's
you
know
already
working
and
working
well.
J
B
Yes,
so
thank
you,
scott,
because
that's
exactly
what
we
were,
we
were
suggesting
when
adopting
this
document,
so
the
the
naming
of
the
document
will
change
and
it
will
just
be
using
js
contact,
okay,
that
was
status
of
existing
work
of
documents
without
a
presentation.
Next
slide,
please
jim.
B
H
Yeah,
I'm
waiting
for
the
ready
for
the
presentation.
Yes,.
K
K
K
K
I
repeat,
but
it's
something
due
to
to
mitiko
I
I
I
didn't
touch
anything
so
regard
to
the
technical
issues.
Alex
said
that
we
need
a
aaa
infrastructure
to
support
reverse
search
and
about
the
privacy
aspects.
Urix
and
alex
agreed
that
the
privacy
construction
section
should
say
something
more
than
the
statement
followed.
The
law
and
one
suggested
to
engage
the
human
rights
protocol
considerations,
work
group
to
review
that
section.
K
K
A
My
internet
is
complaining
about
not
being
solid,
but
here
comes
back.
Okay,.
K
The
the
the
measures
to
to
address
this
the
solutions
are
well
known
and
are
based
on
the
assumption
that
searches
should
shouldn't
be
opened
to
everyone
and
consequently,
limitation
and
restrictions
on
patterns
and
query
capabilities,
making
searches
more
sustainable,
like
those
described
by
the
recent
rfc
documents,
89
77
and
89
82
should
be
differentiated,
differentiated
according
to
the
user
profile.
K
The
second
one
is
secondary
use
the
use
of
collected
personal
information
without
the
individual
individual
content
for
a
purpose
different
from
that
for
which
the
information
was
collected
and
the
third
one
is
misuse.
The
use
of
information
about
an
individual
for
a
part
was
different
from
that,
for
which
the
user
was
requested
and
approved.
K
Secondary
news
and
misuse
seem
to
be
similar,
but
the
first
one
is
related
to
the
use
by
the
data
provider,
while
the
second
one
is
related
to
the
use
by
the
data
consumer
next
tries
next
slide.
Please
two
other
privacy
threads
connected
with
research
search
capability
are
the
delivery
of
pii
as
a
query,
parameter
in
a
get
request
that
is
not
considered
a
best
practice
in
rest,
api
development
and
the
ability
to
detect
facts
about
an
individual
starting
from
a
a
bi.
K
I
don't
know
if
there
is
other
threats,
if,
if
you
know
other
threads
connected
to
this
particular
capability,
please
share
them.
Next,.
H
K
Please,
okay:
before
going
into
much
detail
with
the
analysis
of
privacy
threats
and
the
related
mitigation
measures,
I
would
like
to
briefly
recall
that
some
gdpr
gdpr
principles
refers
to
gdpr
as
the
most
known
privacy,
protection
regulation
and
I'll,
hopefully
demonstrate
in
the
following
that
a
fully
gdpr
compliant
implementation
of
reverse
research
is
feasible.
K
I
will
also
refer
to
openid
the
following
as
a
protocol
for
supporting
a
authentication
authorization
and
accounting
gdpr
states
that
you
must
have
a
lawful
basis
in
order
to
treat
personal
data
in
there
in
the
rdap
context.
It
means
that
other
providers
must
collect,
treat
and
provide
query
capabilities
and
response
contents
in
compliance
with
those
lawful
basis
or
other
local
privacy
protection.
Those
imports.
K
Please
next
slide
now
I
will
I
go
much
in
detail
with
the
measure
to
mitigate
the
privacy,
friends.
K
K
This
can
be
done
by
distinguishing
minimizing
inquiry,
capabilities
and
response
contents
on
a
payroll
base
within
identity
management
in
particular,
innovatives
can
be
achieved
through
the
a
standard
scope
claim.
Other
measures
are
known.
In
particular,
I
would
like
to
outline
that
the
first
one
like
that
is
ensuring
that
the
endpoint
of
the
communication
is
the
one
that
is
intended.
K
The
first
one
is
implemented
in
the
current
reverse
search
specification,
since
the
reverse
session
point
is
distinguished
from
the
other
searches
so
that
it
it's
easy
for
the
programmer
to
protect.
That
and
the
point,
and
and
additionally
protect,
implement
additional
protection
protection
levels
can
be
realized.
K
Protecting
against
the
second
that
is
user
is
usually
outside
the
scope
of
ietf
protocols
in
the
context
of
registration
data
discovery
systems
they
are.
There
are
registry
asking
the
individual
for
a
generic
concept
for
publishing,
including,
for
example,
dot
id,
so
they
rely
on
the
first
gdpr
level
basis
to
return
reducted
or
unreduced
the
data,
but
but
thus
far,
that
concept
has
been
about
a
lookup
capable
capability
like
a
nuisance.
So
this
concept
is
not
about
a
search
capability.
K
K
K
K
C
K
Obviously,
securing
the
transport
channel
that
is
making
provided
information
on
https
a
better
solution
would
be
to
use
a
post
request,
but
the
post
method
is
not
considered
in
adapt
currently
any
anyway
if
these
measures
were
not
considered
sufficient.
K
Similarly,
we
couldn't
omit
the
entities
that
entities
could
be
searched
by
an
entity
named
pattern
like
that
shown
in
the
slide
next
slide.
Please.
K
For
the
first
reported
the
use
case,
the
role
based
access
control
should
be
enough.
The
implementors
could
add
an
implicit
feed
to
a
researcher,
including
reverse
research,
to
let
the
legend
the
registrars
access,
only
the
information
of
their
own,
their
own
objects,
their
own
domains
and
their
own
contacts,
and
not
the
domain
and
concepts
managed
by
other
registrars.
K
Anyway,
I
I
would
like
to
outline
that
the
reverse
church
is
not
the
only
mean
by
which
effects
can
be
detected
in
adapt.
We
we
can
do
the
same
by
using
the
the
standard
searches
next
slide.
Please.
K
K
K
As
a
buzz
as
a
basic
policy,
I
would
recommend
our
providers
to
not
to
not
allow
the
reverse
search
on
the
contact
on
the
contact
information
whose
owners
have
given
their
own
concept
for
publishing.
So
I
would
recommend
it
to
not
use
the
concept
for
publishing
lawful
basis
as
to
in
order
to
support
a
reverse
search
implementation
open
to
everyone.
K
K
B
That's
all
so
thank
you,
mario
for
that
good
assessment
of
all
the
privacy
issues
that
may
be
in
this
document
is
there
before
I
make
my
comments.
Is
there
anybody
that
wants
to
make
any
questions?
Jim
you're.
H
F
What
would
be
the
purpose
of
that?
Is
it
to
provide
legal
advice,
and
I
don't
think
the
itf's
the
position
to
do
that?
I
don't
think
we
want
the
position
of
having
to
give
what's
potential
legal
advice
that
has
all
sorts
of
legal
implications
to
it.
If
it's
just
a
sanity
check
to
say
how
we
considered
all
the
main
considerations,
then
fine,
but
I
think
it'd
be
very
problematical
to
be
on.
F
So
maybe
all
we
need
to
put
here
is
this
is
what
we
think
are
the
privacy
concerns
and
issues.
But
if
you
want
definitive
information
about
these
things,
please
consult
your
local
law
enforcement
and
others
consult
your
own
lawyers.
I
don't
think
going
beyond.
That
is
a
sensible
thing
to
do
in
an
itf
document.
Thank
you.
D
K
K
I'm
trying
to
this
document
was
bought
simply
to
to
give
an
answer
to
the
requirements
for
registrars
wishing
to
searching
their
own
domains
and
contacts,
so
they
have.
They
were
perfectly
supported
by
the
gdpr,
lawful
basis,
the
contract
of
basis
to
to
to
access
this
capability
and
other
providers.
We
are
perfectly
supported
by
by
this
by
this
lawful
basis
in
provisioning
this
capability,
but
a
lot
of
discussion
has
been,
has
been
made
so
far
about
the
privacy
concerns.
K
I
I
I
repeat
since
the
the
the
very
beginning,
the
very
first
beginning
that
I
don't
I
I
my
opinions
that
this
kind
of
search,
like
the
other
searches,
cannot
be
opened
to
everyone,
but
only
to
accredited
users
so
and
the
creative
users
who
are
legitimated
to
access
this
capability,
like
as
the
as
well
the
other
searches.
So
I
think
that
we,
in
my
opinion
we
it
seems
that
outside
we
are
requesting
to
put
together
the
privacy,
the
privacy
concern
with
the
other
concerns
about
cyber
crime,
investigation
and
abuse
investigation.
K
This
is
my
this
is
my
opinion.
This
my
this
is.
This
is
my
basic
principle
to
move
forward
this
document
so.
L
One
two
one:
two:
do
you
hear
me?
Yes?
Well,
I
know
that
gdpr
is
the
the
the
current
example
of
you
know.
Privacy
regulations,
but
I
understand
also
that
you
know
many
governments
are
actually
looking
at
it
and
obviously
they
will
end
up
doing
a
slightly
different
version
of
gdpr.
L
Just
because
you
know
you
know
they
like
to
do
it
their
own
way
and
to
a
point
where,
where
maybe
some
of
the
comments
here
may
be,
you
know
not
relevant
anymore
in
the
sense
that
you
know
for
some
country,
maybe
I'll,
throw
it
something
you
know.
Maybe
general
access
is
just
fine,
but
you
know,
don't
don't
don't
show
anything
or
you
know,
oh
there's
all
kinds
of
variations
that
could
enter
and
that
could
be
based
on
regulation
and
or
policies.
L
So
I'm
I
you
know.
Maybe
we
should
be
almost
and
I'm
concerned
that
it's
going
to
be
a
rattle,
so
you
know
my
suggestion
would
be
to
minimize
the
the
amount
of
of
words
and
stuff
related
to
gdpr
or
privacy,
and
just
say
you
know
you
know,
look
at
the
you
know,
regulation
and
or
policy,
because
we
will
my
take
is
we
will
ever
never
end
that
discussion
because
we'll
get
another?
You
know
a
possible.
L
B
Yeah,
I
agree
with
you
mark.
The
only
thing
where
this
document,
of
course
is
different,
is
because
this
document
is
the
first
time
where
we
aggregate
data
and
that's
why
there
was
quite
some
feedback
from
the
hrpr
group
that
we
should
have
an
extensive.
M
Mrs
yes,
so
as
being
one
of
the
ones,
the
ones
we
have
always
spoken
for,
having
a
privacy
section
on
this,
I
would
say
first,
I
want
to
say
that
I'm
really
impressed
by
the
work
mario
has
put
into
this.
I
think
he
has
done
a
really
good
job
in
going
through
all
the
threats,
and
I
agree
that
we
maybe
shouldn't
take
up
gdpr,
but
all
the
other
privacy
threat
that
mario
has
taken
up,
I
think,
should
be
documented
in
the
privacy
section
and
then
that's
totally.
M
Okay,
then
every
implementer
can
look
at
their
local
laws,
see
what
the
privacy
implications
is
and
where
they
agree
with
the
law
or
disagree
with
the
law
and
implement
it
according
to
it,
and
I
think
that
the
whole
idea
of
the
privacy
section
is
to
just
point
out
this
here.
Are
the
pain
points
look
at
those,
and
I
think
mario
did
an
excellent
job
of
putting
these
out
today.
So
thank
you.
Mario.
E
I
want
to
highlight
some
of
the
things
that
jim
reid
said
that
it's
it's
fine
to
put
privacy
considerations
and
we
should
do
that.
We
we
take
anybody's
input,
regardless
of
what
their
background
is
or
where
they
come
from.
E
If
there
are
any
challenges,
so
we
need
to
look
at
what
if
we
need
privacy
issues
commented
on
suggested
commented
reviewed,
that's
fine
and
we
should
proceed
with
that.
Let's
try
to
keep
the
idea
of
legal
review
out
of
this.
A
So
speaking
as
an
individual
not
not
co-chair,
I
know
that
this
document
stalled
because
you
know
in
this
group
we
couldn't
find
consensus
on
what
should
go
in
the
privacy
consideration
section.
There
is
some
text,
that's
there
and
I
appreciate
that
you
know
mario
kind
of
walked
through.
A
You
know
a
lot
of
the
motivation
and
issues
that
were
considered
in
drafting
the
text.
That's
there.
So
you
know.
Certainly
the
question
to
date
in
this
working
group
is:
are
we
passed
the
privacy
considerations
section
in
the
document
and-
and
you
know
all
of
that's
there,
however,
what
I
wanted.
C
A
Raise
is
is
focusing
more
on
the
technical
side
of
this
document.
I've
been
reflecting
on
this
document
and,
looking
at
it,
and
of
course,
I've
been
involved
in
a
lot
of
rdap
discussions
on
on
on
the
policy
side,
which
I
know
is
not
normally
something
the
ietf
really
thinks
about,
but.
A
Of
that,
I'm
I'm
evolving
a
different
kind
of
technical
perspective
about
this
document
and
thinking
that
there's
some
work
that
we
ought
to
consider
that
I
that
I'd
like
to
propose.
You
know
I
I'm
a
little
concerned
about
the
fact
that
this
document
focuses
on
directionality.
So
it's
called
reverse
search
and
I'm
deciding
that
at
least
for
me.
I'm
not
fond
of
that,
and
and
I'd
like
to
visit,
that
in
in
this
working
group
and-
and
you
know
on
on
the
mailing
list,
the
rdap.
A
This
document
expand,
searching
and
talk
about
other
ways
to
do
additional
kinds
of
searching
and
not
focus
on
directionality,
and
then
there's
also
some
emphasis
on
you
know
being
able
to
search
because
of
particular
elements,
like
name
and
email
address,
and
and
I'm
thinking
you
really
ought
to
abstract
back
and
talk
about
elements
and
and
think
about
you
know,
and
thus
it
would
be
more
applicable
in
in
to
be
more
extensible
rather
than
focusing
on
just
a
couple
of
things
and
how
to
do
those,
it
should
have
an
extensible
mechanism
for
what
you
can
specify
what
you
get
anyway.
A
I
my
my
guess
in
summary,
I'm
beginning
to
develop,
in
my
own
mind
some
technical
questions
about
how
to
approach
what
this
document
does
and
I'm
thinking
I'm
going
to
raise
those
on
the
mailing
list
and
that's
separate
from
the
fact
that
we're
trying
to
deal
with
what
the
privacy
considerations
ought
to
be.
So
I
don't
want
to.
I
don't
want
to
close
that
question
if
that's
been
open,
but
I'm
kind
of
opening
a
new
one
that
I'm
going
to
raise
on
the
mailing
list
to
move
this
forward.
So
that's
it
thanks.
N
N
Okay
yep,
my
graph
is
moving.
Thank
you
very
much
very
briefly,
just
wanted
to
offer
a
comment
on
the
on
one
of
the
slides
here.
These
slides
aren't
numbered
a
little
bit
earlier.
There
was
a
comment
about
allowing
registrars
to
search
only
their
own
contacts.
N
It
occurs
to
me
that
one
this
is
presupposing
a
couple
of
things,
one
about
a
model
of
reverse
search
or
search
to
sort
of
get
to
jim
galvin's
point
that
presupposes
search
at
a
registry
and
a
in
a
registry
registrar
model,
and
you
know
perhaps
we
one
registrars
actually
would
have
their
own
data
already
and
probably
wouldn't
need
to
be
searching
the
registry.
N
So
so
it
might
be
a
possibility
to
simplify
the
the
document
in
that
regard,
and
not
you
know,
concern
themselves
because
I'm
not
really
sure
why
the
registrars
who
need
to
be
searching
the
registry
since
there,
since
the
registrar,
is
really
authoritative
for
the
contact
data
and
the
registry
only
has
a
copy
of
data
which
may
or
may
not
be
accurate.
It
might
be
privacy
proxied
or
something
like
that.
N
So
maybe
that's
an
opportunity
to
simplify
it,
and
then
you
know
just
it
was
interesting
to
see
jim
galvin
bring
that
comment
up
about
some
of
the
differences
in
search
there
and
that's
I'll
be
looking
forward
to
seeing
that
be
explored
on
the
list.
I
hadn't
thought
about
that
when
I
got
into
queue.
Obviously,
since
jim
had
made
it,
but
I
just
thought
I'd
tack
that
on
at
the
end,
thank
you
very
much.
B
F
Thanks
antoine,
I
hope
this
is
the
right
gem
this
time
I
just
want
to
go
back
to
this
issue
about
the
privacy
consideration
stuff
mario's
done
a
great
job
of
enumerating.
Many
of
these
privacy
concerns
and
mitigation
techniques,
and
I
was
not
trying
to
disparage
that
work
in
any
way,
but
I
think
to
make
some
progress
with
this
document
on
that
particular
area.
F
F
B
Thank
you,
jim
and
you
know.
If
you
support
this,
you
know
there
should
be
consensus
on
the
on
the
mailing
list
and
that's
what
we've
done
so
far
and
so
far
there
was
no
consensus
on
the
mainly
this
on
the
privacy
consideration
section.
So
if
there's
consensus
on
the
mailing
list,
then
we
can
move
this
document
forward
and
mario
I'll
leave
you
to.
H
K
They
simply
rely
on
the
information
stored
by
the
registry
maintained
by
the
registry
so
that
they
they
don't
have
enough
that
they
don't
spend
the
effort
in
in
implementing
and
and
maintaining
their
own
in
information
about
contents.
This
and
the
other-
and
it's
here,
for
example,
they
simply
write
rely
on
the
fact
that
that
information
is
maintained
by
the
registry.
So
we
are.
K
Frequently
requested
for
for,
for
example,
the
number
of
contacts
technical
contacts
associated
to
this
domain
or
what
are
the
numbers?
Sorry:
what
are
they
the
the
domains
associated
to
this
technical
content?
What
what
are
the
domains
associated
to
these
registers,
because
they
don't
have
this
information?
K
You,
you
cannot
as
a
registrar,
you
cannot
access
the
information
of
another
registrar.
So
this
is
why
I
imagine
that
that
registrars
cannot
manage
the
information
of
the
other
register
and
it
makes
sense
for
us
that
a
registrar
could
search
could
execute
a
a
reverse
search
on
their
own
on
on
his
own
domains
or
contacts,
because
they
don't
have
this
information.
J
Juan
yes,
scott,
holland
back
and
while
we
were
talking
here,
I
just
I
had
a
revelation.
Mario,
you
had
asserted
in
your
deck
that
this
thing
that
we
are
calling
reverse
search
has
some
of
the
same
concerns
properties.
You
know
whatever
we
want
to
call
it
as
the
search
mechanism
that's
currently
described
in
7482,
and
I
I
think
I
can
think
of
one
very
tangible
difference
and
that's
what's
in
7482,
is
about
searching
using
pattern.
J
Matching
techniques
right,
but
what
we
are
calling
this
thing
called
reverse
search
is
more
about
finding
relationships
and-
and
I
can
see
them
having
very
different
privacy
considerations
if
you're,
if
you're
allowing
search
you
know
to
find
relationships,
you're,
potentially
going
to
find
things
that
exist
in
the
database.
That
aren't
necessarily
meant
to
be
exposed.
J
You
know,
whereas
the
stuff
that
we've
got
in
7482
is
more
about,
as
I
said,
you're
just
doing
very
simple
pattern
matching
anyway.
I
wanted
to
throw
that
out
there,
because
I
think
if
we
start
talking
about
you
know
how
we
look
at
search
in
general.
That
distinction
may
be
important.
K
When
I
talk
about
the
that
other
other
searches,
then
research
are
able
to
to
detect
facts
about
the
individual.
I
would
like
to
to
to
to
give
you
this
example.
I
use
a
lookup
domain
to
get
the
information
about
the
domain.
K
For
example,
I
know
I
get
the
name
server
and
rely
on
the
fact
that,
for
example,
if
normally,
if
a
known
registrant
owner
more
as
more
than
one
domains,
all
these
domains
are
associated
with
the
same
and
server.
So
I
can
use
the
the
search
domain.
I
can
search
domains
by
net
survey,
name
to
collect
all
the
domains
related
to
the
distant
server
and
again,
and
I
can
check
what
are
the
domains
owned
by
the
the
same,
the
same
owner.
K
So,
in
my
opinion,
the
the
the
the
the
means
through,
which,
in
order
that
we
can
detect
parts,
are
various,
but
I
know
that
there
are
search
patterns,
but
anyway,.
K
In
the
example
of
entities,
for
example,
in
in
the
example
of
the
searching
entities
by
by
the
name,
the
name,
that
would
be
a
plain
name-
not
a
search
pattern,
including
a
white
card.
So
in
this
case
you
are
delivering
a
a
get
request
through
the
network,
with
the
with
the
with
a
plain
name
that
presumably
will
be
stored
in
some
proxy.
But
this
is
the
the
protocol,
so
the
best
practice
suggests
to
to
provide
personal
information
through
a
post
meet
on
the.
K
K
It
is
different
in
the
sense
that
we
we
we
we,
we
came
from
a
a
world
where,
where
there
was
the
wiis
and
whose
response
was
a
look
up,
the
lookup
response
now
we
have
the
lookup
responses,
look
up,
searches
and
responses
to
look
up,
searches
and
look
up
the
queries
and
also
search
queries.
So
we
we
can
provide
a
collection
of
objects,
not
only
one
object.
So
in
this.
K
In
this
sense,
it
seems
to
me
that
reverse
search
is
not
so
particular
is
similar
to
the
other
searches.
B
Okay,
thank
you,
mario.
Then
we
will
move
on
to
our
next
presentation
and
let's
get
the
privacy
section
discussed
on
the
mailing
list.
Next
presentation
will
be
mark
planche
about
74
84
bits
mark
go
ahead.
Yes,
do
you
hear
me.
L
Yes,
excellent.
Thank
you,
okay,
so
this
is
about
rfc
7484
next
version
next
slide,
please.
L
L
L
So
for
serrata,
the
person
who
reported
saying
that
you
know
there's
a
text
about
what
happens.
If
you
don't
get
any
response
for
the
object,
you're
looking
for
in
dns,
you
can
query
the
dns
and
you
know,
do
various
stuff
and
the
the
person
says
either
change
they.
You
know
change
the
the
text
or
remove
the
paragraph
next
slide,
so
the
current
draft
actually
added
you
know,
change
a
bit
the
detects,
but
I'm
proposing
instead
that
we
just
delete
this
by
this
whole
paragraph.
L
I
think
that
is
remaining
to
the
the
you
know,
discussion.
We
had
a
long
time
ago
about
you
know.
If
this
is
this,
you
know
do
we
need
to
cash
stuff,
and
you
know
all
that
I
think
that's
roughly
relevant
based
on
experience,
and
I
can
claim
to
have
some
experience
in
this
having
written
a
few
of
the
adapt
clients
and
servers.
L
I
think
we
should
just
delete
that.
It's
you
know
it's
up
to
implementation.
To
do
you
know
all
kind
of
stuff
they
want,
but
you
know
from
the
purpose
of
the
document
which
is
essentially
saying
here:
here's
a
way
you
can
find
the
server
the
authoritative
server
of
the
for
the
object,
you're.
Looking
for
all
everything
else
is
to
me
out
of
scope.
So
my
suggestion
is
we
delete
this
paragraph.
L
I
would
suggest
that
I
go
through
all
the
slides
and
I'll
take
the
questions
at
the
end.
If
you
don't
mind
next
slide,
there
was
an
errata.
This
there
was
a
slash
missing
in
the
example,
so
needs
to
be
done,
agreed
it's
up
already
in
the
draft
next
slide.
So
those
are
the
two
erratas
for
that
were
provided
to
the
rc
editor
next
I'll
go
through
some
changes.
There
was
a
suggestion
from
gavin
brown
to
say.
L
Essentially
all
our
adapt
endpoints
referred
by
the
urls
in
the
area
must
return
identical
responses
for
the
same
airdac,
query
and
next
slide.
So
that's
in
the
current
draft
and
then
also
george
michaelson,
said
I
went
further
down
in
saying
yeah
it
should
we
should
ref.
All
the
endpoints
referenced
by
the
urls
should
in
the
area
should
must
return
an
identical
response,
but
notices
may
have
you
know
things
different
because
they
may
say
things
here
and
there
I
maybe
I'm
in
the
you
know,
make
it
short.
L
You
know
mood,
but
I
would
essentially
also
just
not
essentially
be
silent
on
this.
You
know,
I'm
not
sure
we're
actually
doing
something
useful
here
in
you
know
even
saying
that
the
two
are
that
all
the
servers
who
responds
the
same
thing-
and
I
think
the
the
the
comment
from
george
actually
just
show
it
where
it
may
make
sense
that
other
you
know,
different
servers
may
answer
different.
You
know
just
some
variations
of
the
same
thing
while
not,
I
guess.
L
Comments
on
the
mailing-ness,
I
think
that
was
from
patrick
also
there
was
a
comment
about
is:
do
we
have
some
some
data
about
ayana
having
you
know
any
issues
on
on
serving
those
files
and
and
asking
for
statistics?
I
didn't
get
any
statistics,
but
response
from
ayanna
kim
david
says:
there's
no
issue
and
you
know
frankly,
the
size
of
those
files
are
similar
to
when
you
open
a
website
currently
and
you
download
a
you-
know,
javascript
framework
file.
L
So
I'm
not
sure
that's
you
know
really
a
problem
and
as
soon
as
you
get
a
cdn
up,
then
it's
not
an
issue.
The
sentence
has
been
changed
slightly
to
say
that
no
issues
has
been
reported
regarding
the
load
of
the
service,
so
change
to
sr.
There
was
a
comment
that
we
should
change
back
to
srv
records.
I
am
not
sure
we
want
to
reopen
the
whole
discussion
again.
We
add
in
words
pros
and
cons
and
each
approaches.
L
So
I'm
kind
of
rejecting
that
comment.
Unless
you
want
to
you
know
the
group
want
to
reopen
the
whole
discussion.
There
was
other
comments
about
restricting
to
https
only
url
in
the
services
area.
Instead
of
you
know,
having
http
also
given
that
some
policies
for
some
you
know,
environments
are
restricting
to
https
only
and
then
the
itf
is
https,
I'm
kind
of
you
know
in
between
there
it
to
me
it's
a
bit
out.
L
You
know
it's
a
bit
policy
related
in
the
sense
that
you
know,
maybe
somewhere
you
know
serving
something,
maybe
on
http
for
some
reason,
but
I'm
open
to
anything
and
I'm
not
sure
we
have
a
conclusion
in
the
mailing
list
about
this
topic
next
slide.
L
From
so
this
is
kind
of
a
that.
I
got
the
review
from
the
doc
shepherd
there's
a
lot
of
things
there
I
put
it
there,
mostly
for
you
know,
making
sure
that
you
know
I'm
transparent
and
I'm
saying
everything
so
I'm
kind
of
okay
with
most
of
the
comments
he
made.
You
know
in
the
first
slide
here.
Only
thing
that
I
will
talk
later
is
about
implementation
status.
So
all
so
there
there
were
a
few
comments.
L
I
was
not
sure
it
was
really
needed,
but
you
know
I'm
fine
with
you
know,
adding
them
next
slide.
Other
comments
from
the
duck
shepherd
there
was
yeah.
There
was
an
entry
of
the
so
there's
a
text
in
the
draft
and
the
rfc
that
says
the
entry
of
the
root
of
the
domain
space
is
specified
as
essentially
an
empty
string.
L
L
You
know
put
his
inf
server
up
and
serving
kind
of
the
root
of
the
main
space
that
that
sentence
is
appropriate
and
needed.
So
I
disagree
with
that
one,
and
there
was
some
discussion,
some
comments
about
using
ipv4
and
ipv6
and
as
a
private
reserve
for
documentation,
I'm
using
some
of
those.
L
I
was
aware
of
all
those
but
I'll.
Try
to
you
know
change
the
example,
so
I'm
only
using
those
so
we'll
we'll.
Hopefully
that
will
work
and
there's
a
catch
of
of.
You
know
a
little
inconsistency
in
the
example,
so
we'll
do
that
too.
Next
slide.
L
So
again
es
ipv6
address
for
documentation.
There's
a
common
about.
You
know
an
extra
zero.
You
know
I
you
know
I
was
trying
to
make
clear,
but
you
know
I
can
remove
as
number
reserved
for
documentation
also
next
slide
and
and
again
about.
L
Yeah
the
same
paragraph
about
you
know
in
terms
of
a
domain
object,
you
could
do
dns
queries
and
the
guy
is
saying
the
doc
shepard
says.
Maybe
we
should
you
know,
remove
that
sentence,
I'm
suggesting
we
remove
the
whole
paragraph.
Therefore,
this
guy,
you
know
gun,
and
the
final
one
is,
I
think,
from
his
comments
is
about
a
reference
to
a
draft
which,
and
I'm
not
aware
that
this
document
has
been
published
as
an
rfc
and
but
it
I
think,
still
appropriate
to
refer
to
that
work.
L
So
to
my
knowledge,
we
need
a
kind
of
implementation
status
in
documents
going
moving
forward
to
standard
yes,
so
here's
a
call
to
everybody
who
have
done
a
net,
a
quote:
quote-unquote
nation-
that
you
know
it's
not
really
a
full
protocol
itself,
but
you
know
so
if
you
fetch
and
parse
one
of
the
bootstrap
files,
could
you
send
me
an
email
about
about
that,
and
so
I
can
collect
it
and
create
a
section
with
implementation
status.
As
far
as
I
know,
there
is
the
mobile
app
I
wrote.
L
L
So
if
you
have,
if
you
are
parsing
that
file
fetch
and
parse
or
then
please
contact
me,
you
know
by
email,
so
I'll
kind
of
collect
all
those
implementation
status,
and
I
think
I'm
mostly
done
next
slide.
L
So
looking
for
comments
on
all
the
you
know,
topics
I
discuss
if,
given
that,
if
changes
are
agreed
for
all
those
changes
and
that
you
trust
me
in
applying
it
and
I'm
receiving
implementation
information
from
implementers,
you
know
maybe
we're
ready
for
publication.
So
that's
the
end
of
my
presentation.
Looking
for
comments.
C
Very
quick
and
simple
go
for
it.
It's
simple
enough.
I
don't
see
any
changes
that
would
impact
any
protocol
details
or
anything
waiting
for
implementation
reports
is
a
good
idea,
but
otherwise
please
go
forward
and
please
get
the
document
out
as
fast
as
possible.
C
B
P
First,
let's
begin
with
a
short
reminder
about
the
current
email
address
and
feminization
status.
It
was
specified
in
the
set
of
rfcs.
P
6530-6533,
it
allows
non-ascii
left
path
of
email
addresses
and
requires
more
or
less
explicit
protocol
changes
for
all
the
protocols
that
refer
to
the
previous
standard,
describing
the
email
address
next
type,
please.
P
My
intention
is
introduce
the
entrance,
the
support
of
yeah
in
epp
protocol,
and
I
think
that
such
introducing
should
cover
all
the
epp
objects
that
support
email
as
an
attribute,
and
the
such
addresses
should
be
first
class
option.
Next
slide
is
so
after
the
fruitful
discussion
on
the
mailing
list
and
off
list.
P
P
It
just
applies
the
functional
capability
to
existing
set
of
attributes
and
objects.
In
this
document,
we
introduce
functional,
ep
extension
for
the
email
address
address
field.
Please
next
slide.
P
In
short,
it
doesn't
introduce
any
xml
schema
changes,
because
the
current
syntax
formally
allows
yeah
addresses,
oh,
but
we
apply
the
processing
rules
on
the
president
of
the
extension
support
demonstrated
in
the
legend
comment
from
the
client
and
greeting
from
server.
The
support
is
indicated
by
a
special
namespace,
nay
next
slide.
P
P
If
the
server
should
accept
such
addresses
for
all
the
registry
zones
which
are
operated
in
the
current
session
and
for
all
the
objects,
the
addresses
should
be
validated.
According
to
the
aaa
validation
rules,
their
email
attributes
should
be
stored
and
returned,
as
is
according
to
the
universal
acceptance.
Rules
in
the
part
of
email
addresses
next
slide.
Please.
P
When
the
extension
is
negotiated,
the
client
should
provide
the
ai
compatible
addresses
for
all
the
email
properties
in
the
current
session.
P
The
same
examples:
at
the
end,
the
maple
clan,
should
apply
the
such
addresses
for
all
the
registered
zones
so
that
are
accessible
to
the
client
in
the
current
session
and
accept
such
addresses
and
the
ep
responses
for
all
email
reboots
received
from
the
server
next
slide.
Please!
P
P
So
if
server
supports
ai
and
client
does
not,
then
the
server
should
validate
the
email
property.
The
email
reports
sent
by
client
using
the
sqml
validation
rules
and.
P
If
clear,
if
the
email
property
is
optional
and
the
client
supplies
it,
the
server
should
validate
it
using
the
ascii
validation
rules
either.
Then
next
slide.
Please.
P
If
a
server
sends
a
yamaha
tribute
in
response,
the
server
should
the
the
server
must
validate
whether
the
email
property
is
not
asking
one,
and
if
so,
the
server
should
return
the
predefined
or,
if
it's
asking
it
should
remain,
it
should
return.
The
original
value
of
the
email
address
when
such
attribute
is
optional.
Server
again
must
validate
whether
it's
internationals
or
not,
and
in
case
of
a
in
case
of
ai.
P
When
we
have
a
client
that
supports
yeah
addresses,
but
not
supporting
server,
when
the
property
is
required,
according
to
the
ep,
syntax
and
the
client
has
no
alternative
ask
address,
but
only
international
one.
The
client
must
provide
some
predefined
placeholder
email
address
to
indicate
that,
in
fact,
it's
a.
P
When
this
property
is
optional
and
the
client
has
only
national
address,
the
client
should
emit
the
email
property.
Then
next
slide
please
so
the
placeholder
address
is
not
defined.
Yet
in
the
document,
I
think
that
there
are
two
possible
options.
First
of
all,
is
using
some
well-known
address,
for
example,
from
example.com,
and
the
other
possible
option
is
using
the
registry
specific
address
which
can
be
set
by
the
registry
from
one
of
the
controlled.
P
Namespaces
to
ensure
that
it
will
not
clash
with
any
really
possible
address
the
next
slide.
Please,
as
we
have
a
discussion
on
the
mailing
list,
as
I
think
that
it's
important
to
add
the
support
of
the
international
email
addresses
to
the
ep
protocol.
P
I
kindly
asked
the
working
group
to
adopt
this
document
and
begin
the
process
of
working
with
it
as
a
working
documents.
Many
thanks.
B
P
M
M
P
A
fair
point,
but
I'm
not
sure
it's
in
the
scope
of
the
iatf.
C
C
Secondly,
I
think
we
need
to
double
check
this,
but
as
far
as
I
know
for
just
getting
the
namespace
uri,
I
don't
think
your
an
rsc
is
even
required.
Isn't
it
so?
The
xml
namespace
registry
is
probably
specification
required,
so
a
local
specification
of
your
registry
would
probably
do
enough
for
the
namespace
registration.
C
P
Foreign
space,
but
I
think
it
would
be
very
useful
to
have
a
universal
way
to
deal
with
international
email
addresses
that
can
be
used
with
all
the
registries
and
registers
instead
of
currently
locally
defined
operation.
I
Can
you
hear
me
yep?
Yes,
there
you
go
fantastic,
hey
I
wanted
to
jump
in
and
just
to
help.
The
working
group
understand
that
this
is
a
new
form
of
epp
extension.
So
we
said
it's
not
an
extension.
It
really
is
an
extension,
but
it's
a
different
form
because
it
doesn't
add
any
new
elements.
It's
actually
an
override
of
the
existing
elements
that
have
been
negotiated
in
the
evp
session.
So
this
provides
for
a
lot
more
easy
implementation.
I
But
it's
really
important
from
a
signaling
perspective,
because
if
a
server
in
fact
supports
international
email
addresses,
they
can
communicate
that
but
they're
committing
to
a
specific
set
of
behavior
and
similarly
the
client
is
also
signaling
and
agreeing
to
a
particular
behavior
as
well.
So
yes,
you
could
go
and
register
a
name
space,
but
there's
a
lot
more
to
it
than
registering
a
namespace.
There
are
certain
obligations
that
are
necessary
for
this
to
work
and
then,
in
addition,
I
wanted
to
hit
it
on
the
placeholder
text.
I
That
is
the
probably
the
biggest
item
for
this
working
group
to
figure
out,
because,
as
I
guess,
it
was
alexander
that
brought
up
the
fact
that
there
may
be
a
legal
requirement
to
do
it,
but
from
a
protocol
perspective,
it's
a
required
element,
it's
up
to
server,
pulse
and
decide
what
to
do
with
it
if
they
require
something
other
than
the
placeholder.
I
So
but
there's
not
a
whole
lot
of
other
options
that
we
could
think
of,
because
if
it's
required
and
the
client
doesn't
have
the
appropriate
value
either
they
can't
send
it
or
the
server
will
fail
it
or
they
pass
a
placeholder
element
and
the
server
will
accept
it.
So
that's
it.
B
P
B
A
Well,
my
connection
seems
to
be
holding
out,
so
that's
a
good
thing,
otherwise
it
would
have
dropped
me
like
it
did
before
and
it
dropped
all
the
presentation
sort
of
ugly
okay.
So
you
know,
as
chairs
we
have
tried.
Oh
james
cool,
do
you
have
your
hand
up?
Is
that
an
old
hand,
organizing.
A
On
so
you
know,
the
chairs
got
together
and
we
just
sort
of
made
up
a
slide
and
I'm
being
fair
and
telling
you
what's
going
on.
You
know
we're
trying
to
manage
our
milestones
and
we
don't
seem
to
get
a
lot
of
input
from
folks
here
on
the
group.
So
we
just
kind
of
made
some
stuff
up
here
and
that's
just
a
way
of
leaning
on
folks
and
saying
you
know,
if
you
don't
like
it,
that's
fine.
A
Please
propose
something
different
that
keeps
things
organized
and
we're
happy
to
take
that
on
board.
So
the
things
which
are
in
italics
here
are
already
on
our
milestone
list.
A
The
things
that
are
not
in
italics
are
new
items
and
for
the
items
that
were
on
the
list
you
you
can
see
in
parentheses
there
what
the
old
milestone
date
was,
and
so
we're
just
proposing
a
new
date
and
we've
just
kind
of
structured.
What
we
think
appears
to
be
the
energy
in
the
working
group
as
far
as
moving
things
forward,
and-
and
so
we
just
kind
of
laid
things
out
in
that
way
and
gave
ourselves
a
little
time
to
go
through
the
different
documents.
A
So
I
mean
there
was
a
little
bit
of
method
in
our
methodology
here,
but
you
know
frankly,
it
was
just
our
view
of
what
we
see
going
on
in
the
group.
As
always,
you
know
our
work
is
dependent
on
people
wanting
to
push
it
forward.
So,
if
you
feel
like
you
want
to
jump
on
something
and
move
it
along
quicker,
then
you
know
we're
happy
to
negotiate
some
milestones
here,
move
stuff
around.
A
We
basically
took
a
model
of
trying
to
order
the
documents
in
terms
of
what
we
think
is
most
relevant,
and
then
we,
we
deliberately
just
kind
of
chose
every
two
months
to
sort
of
separate
the
documents
a
little
bit.
I
mean
we
seem
to
mostly
do
one
thing
at
a
time
in
this
group
just
feels
like
the
way
that
we
tend
to
work
best,
so
we
kind
of
ordered
them
based
on
what
we
think
is.
A
You
know
discussion
that
has
to
happen
or
is
happening,
and
you
know
again
you
you
can
disagree
with
us.
If
you
don't
like
this
order.
Registry
maintenance
we're
just
kind
of
carrying
forward.
We
kind
of
figured
that
one's
pretty
close
to
done.
You
know,
7484
biz
is
a
new
document.
We
just
think
we'll
do
that
next,
because
I
don't
think
there's
a
lot
of
discussion
or
work
that
has
to
happen
there.
We
just
talked
about
rdap
search
a
bit.
A
A
That's
my
personal
contribution,
as
opposed
to
chair
contribution,
so
we
kind
of
move
things
that
way
with
registration
reporting,
there's
a
bit
of
coordination
to
do
with
registrars
on
the
icann
side,
so
it
just
felt
like
pushing
that
out.
A
little
bit
seemed
like
the
right
thing
to
do.
Allow
some
extra
time
for
some
discussion
there
on
that
topic.
A
A
I
would
imagine
in
this
just
like
with
registration
reporting,
will
reach
out
to
do
a
little
joint
work,
specifically
with
icann's
tech,
ops
group,
where
the
registrars
and
their
technical
folks
tend
to
sit
and
we'll
will
sort
of
create
an
interim
meeting
and
an
opportunity
to
have
a
joint
meeting.
So
we
can
get
some
really
good
input
on
that
side.
With
respect
to
that
issue,
so
it
felt
appropriate
to
push
that
out
and
then,
as
scott
kind
of
said,
with
open
id
we're
kind
of
waiting
for
the
opportunity
to
do
some.
A
Testing
and
implementation
experience
I
mean
yeah,
we
kind
of
have
a
really
nice
document
there.
It
seems
pretty
well
pretty
stable,
but
then
again
we're
waiting
for
an
external
event.
You
know
we're
expecting.
You
know
some
policy
work
on
the
icann
side.
That
will
motivate
the
deployment
of
some
kind
of
authenticated
queries
in
our
dap,
and
thus
we
will
actually
want
to
engage
in
testing
and
trying
some
things
out
and
seeing
if
it
works,
and
so
it
seems
appropriate
to
hold
that
document.
A
J
Me
yeah
thanks
jim
scott
holland,
back
yeah.
I
I
should
just
remind
folks
that,
back
when
we
were
doing
some
of
the
original
rdap
pilot
work
in
the
icann
context,
there
were
several
implementations
of
this
particular
draft.
You
know
that
demonstrated
both
function
and
interoperability
right,
so
you
know
modulo
anything
we
might
decide
to
change.
I
mean
I
think,
we've
already
kind
of
checked
that
particular
box.
The
real
issue
here
is:
is
there
going
to
be
anything
changing
in
the
policy
space
such
that
we
have
to
change?
J
Some
of
the
you
know,
proposals
for
registering
attributes
associated
with
identities.
Okay,
I
mean
obviously,
that
that's
not
all
of
it.
Of
course
I
mean
over
time
things
might
we
might
have
to
change
more,
but
basic
functionality.
We've
got
that
nailed
in
fact,
there's
an
implementation
status
section
in
the
document
that
describes
some
of
those
past
successes
already.
A
Thanks
for
that,
scott,
you
know
I
agree
with
you
you're
absolutely
right.
You
know
the
document
really
is
pretty
stable.
I
guess
you
know
just
kind
of
stepping
back
a
bit.
A
I
might
restate
what
I
said
in
the
form
of
you
know:
there's
just
no
urgency
for
this
at
the
moment,
and
so
there's
no
pain
if
you
will
involved
in
pausing,
while
we
wait
for
some
urgent
need
for
it
to
give
us
a
chance
to
test
some
things
and
and
see
how
it
really
works,
you
know
beyond
just
the
the
technical
elements
of
it,
so
hopefully
there's
not
a
lot
there,
but
we're
just
giving
ourselves
time
and
keeping
it
letting
it
simmer.
A
I
think
that
was
the
word
to
use
scott,
but
just
let
it
simmer
for
a
while
longer
it's
it's
not
in
the
way.
So
anyway,.
A
We'll
add
that
you
know
that's
it's
not
on
the
list
at
the
moment,
because
it's
not
yet
adopted,
but
if
we
get
past
that
far
we'll
we'll
slot
that
in
here
somewhere
along
the
way,
you
know
anyway,
again,
I
guess
the
end
of
this
is
you
know
this
is
our
proposal
at
least
we'll
update
our
milestones
this
way
in
fairness,
you
know
we
should
send
this
off
to
the
mailing
list
and
just
you
know,
wait
to
see
if
there's
any
real
discussion,
but
I
would
say
that
unless
anyone
objects
or
wants
to
make
a
different
proposal,
we
will
update
our
milestones
to
reflect
this
sometime
in
the
next
couple
of
weeks,
just
so
that
we're
accurately
recording
our
level
of
effort
and
our
work
here.
B
A
I
guess
that's
it,
there's
no
other
questions
back
to
you,
antoine.
B
E
Well,
I'd
like
to
say
this
is
barry,
I'd
like
to
say
thanks
guys
for
all
the
work,
you
guys
do,
the
the
chairs,
the
working
group,
everybody.
This
is
a
productive
working
group
and
and
I'm
pleased
with
that,
and
and
so
thanks
and
I'm
turning
this
over
this
week
to
murray
who
co-chaired
the
amusingly
named
working
group
that
created
rdap
in
the
first
place
and
is
now
back
as
your
as
y'all's
ads.
So
murray.
You
want
to
say,
hey.
R
Sure
morning,
everyone
where
I
am
and
I'm
looking
forward
to
working
with
you
all
this
looks
like
this
has
been
a
pretty
productive
working
group.
So
far,
no
big
contentions,
which
is
a
reload
off
my
mind.
So
thank
you,
barry
for
all
the
work
you
did.
I
just
counted
something
like
nine.
Nine
or
ten
documents
have
gone
through
with
your
name
on
them
as
the
sponsoring
id
so
more
than
any
other
id.
That's
worked
with
this
one,
so
you
know.
B
Yeah-
and
that
was
actually
also
my
other
any
other
business
topic
that
I
want
to
discuss
jim
and
I
had
some
some
other
area
directors
with
this
working
group
and
with
our
predecessor,
work
group
and
barry
was
with
us
the
longest,
and
we
must
say
we
want
to
thank
very,
very
much
he's
been
very
supportive
with
us
and
he
understood
how
this
working
group
works
very
much.
So
I
hope
you
will
all
join
me
and
thank
barry
for
his
fantastic
job
that
he
did.
Thank
you.
B
A
Yeah,
let
me
jump
the
cue
a
little
bit
on
on
alexander,
since
you
know,
barry.
C
J
A
The
any
other
business
and
little
chairs
prerogative,
sorry
alex
but
yeah
I
want
to
thank
barry.
You
know
very
much.
It
has
certainly
has
been
a
pleasure
to
to
work
with
barry.
As
antoine
said
he's
been
with
us
the
longest.
Sometimes
I
feel
a
little
bit
like
the
orphan
working
group.
We
kind
of
like
we're
we're
marching.
A
For
a
while
they're
like
nobody
really
wanted
us,
but
barry
hung
in
there
and
kept
us
on
the
straight
and
narrow
and
and
and
has
been
very
helpful
to
us
a
couple
of
times
here
as
we
bumped
into
some
interesting
situations.
But
it's
all
been
very
good.
We're
very
happy
very
happy
to
return
back
to
murray
with
respect
to
rdap,
especially
but
looking
forward
to
you
know
having
you
as
our
as
our
a
d
and
this
and
and
we
hope
you
stick
it
out-
for
your
entire.
D
A
C
Thank
you
antoine
just
just
a
short,
maybe
maybe
no,
no!
No!
I
want
I
didn't
want
to
share
the
screen.
I
didn't
want
to
send
video
there
you
go,
I
felt
going
to
make
an
observation,
and
that
is
I.
I
think
that
we
can
we
as
a
working
group.
C
We
can
actually
be
pretty
quick
if
we
focus
on
a
certain
topic
and
that
topic
doesn't
have
any
external
dependencies
yeah
we
get
really
slow
when
it
gets
to
issues
that
are
like
a
little
bit
outside
of
the
scope
of
the
working
club.
C
Let
me
put
it
like
the
privacy
discussion
on
the
reverse
search
thing,
because
I
think
you
would
be
able
to
like
finalize
the
technical
parts
of
that
racine
wii
yeah
and
that
that's
true
for
a
lot
of
the
other
drafts,
maybe
as
well
as
as
soon
as
there
is
something
that's
like
well,
either
controversial
or
not
not
in
the
perfect
technical
part
of
the
of
the
competence
of
the
work
group,
then
it
gets
really
slow
so
and
and
for
that,
I
think
that
injury
meetings,
focusing
as
a
working
session
on
a
specific
document
with
the
interested
people
could
work
really
well
and
after
that
I
think
the
only
thing
that
we
need
to
do
is
brought
enough
people
to
to
say
yes
to
the
working
group
last
call.
C
So
that's
maybe
an
observation
with
regards
to
the
milestones,
because
I
think
some
of
the
milestones
are
like
years
out
there
in
the
future,
and
I
think
we
should
maybe
reiterate
all
the
milestones
and
look
at
whether
any
of
those
documents
has
any
external
or
non-technical
issue
that
prevents
us
from
going
forward.
Yeah.
C
I
mean
open
ids,
for
example,
an
an
example
where
we
probably
depend
on
on
the
on
whatever
cpa
tech.
Backups
comes
out
together
with
the
I
can
policy
people,
but
there
are
hopefully
other
things
on
the
milestones
list
which
are
which
are
quicker
as
soon
as
we
find
a
group
of
a
few
people
who
are
willing
to
spend
an
afternoon
or
maybe
even
two
afternoons
on
it.
Just
an
observation.
B
That's
that's.
Also,
of
course,
one
of
the
observations
that
we
have.
You
know
sometimes
there's
a
lot
of
direction
on
the
document,
and
things
goes
fast
and
everybody
agrees,
but
sometimes
it
also
takes
time
for
people
to
to
to
read
and
and
it's
mostly
the
same
people.
So
yes,
I
would
ver,
I
think,
jim
and
I
would
very
much
like
you
know
everybody
that's
in
the
tech
house
to
also
be
in
the
regex
group,
but
I
only
see
37
people
on
my
screen
now
and
not
100..
A
Yeah,
I
think
I'll
just
add
one
takeaway
I
took
from
what
you
said
alex
I
mean
you're
right,
but
one
specific,
concrete,
takeaway
I
took
from
what
you
just
said
is
we
should
make
our
milestones
more
visible
to
ourselves
on
a
regular
basis.
A
We
don't
often
go
through
them.
You
know
we
did
this
time
because
we
kind
of
had
a
lot
of
publications
last
year
with
a
lot
of
change,
so
we
we
took
a
a
visit
of
them,
but
I
know
that
other
working
groups
tend
to
put
the
milestone
list
in
front
of
themselves.
You
know
every
meeting
and
we
should
certainly
do
that,
and
we
can
do
that
here
for
ourselves
too,
we
can
make
them
more
visible,
just
to
remind
people
of
what's
there
in
the
documentation.
A
A
second
takeaway
I
took
from
what
you
said
is
inter
meetings.
I
want
to
remind
the
working
group
that
we've
had
some
very
successful
inter
meetings
here.
The
fee
extension
draft
was
one
in
particular
that
sticks
out
in
my
mind.
You
know
it
was
roger
and
jody
who
had
a
particular
interest
in
moving
that
forward
and
in
fact
they
sponsored
the
interim
meetings,
and
you
know
they
were,
you
know,
set
up
and
had
they
were.
They
were
remote
meetings.
A
So
it
wasn't
even
a
physical
meeting
that
you
had
to
go
be
there
and
they
really
worked
out
very
well.
They
were,
they
were
specific,
a
working
meeting,
they
had
an
agenda
technical
issues
and
it
was
just
focused
and-
and
so
I
think
that
that
helped
move
that
document
along
it
languished
for
a
long
time
until
those
guys
picked
it
up
and
moved
it
along,
and
so
that
opportunity
exists,
and
you
know
we'll
support
that,
and
the
itef
has
facilities
for
supporting
that
too.
A
If
you
need
a
way
to
run
the
meeting,
but
you
know
I
mean
there's
no
obligation
really
as
long
as
a
group
of
people
want
to
meet
as
long
as
you
declare
it
and
make
it
open
for
anybody,
you
can
have
any
kind
of
meeting.
You
want
any
way
that
you
want,
there's
no
real
requirements
except
that
it'd
be
visible
and
possible.
For
you
know,
people
to
join
and
and
we'll
help
you
and
support
that.
So
you
know
thanks
for
that
alex
those
are
my
two
key
takeaways
from
what
you
said.