►
From YouTube: IETF106-REGEXT-20191120-1000
Description
REGEXT meeting session at IETF106
2019/11/20 1000
https://datatracker.ietf.org/meeting/106/proceedings/
C
A
D
Ok
good
morning,
everybody,
this
is
the
regex
working
group.
My
name
is
John
Thomas,
who
is
my
co-chair?
Jim
Gavin
welcome
to
Singapore
and
of
course,
the
first
thing
we
do
on
the
agenda
is
read
the
note.
Well
anything
you
say
here
will
be
recorded
and
will
be
property
of
the
ITF
so
that
you
all
know
quick,
look
at
the
agenda.
We
have
some
extra
welcome
and
introduction
statements.
So
please
pay
attention
to
that.
We
have
a
course
on
our
existing
document.
7.
D
We
have
a
report
from
the
interim
working
group
meeting
and
so
we
work.
So,
let's
start
we
have
described
which
is
Barry
our
area
director
and
we
have
a
minutes
taker
who
is
with
Rick
Wilhelm.
Thank
you
Rick
and
Barry
for
doing
that
note.
Well,
we
just
read
and
of
course
one
of
the
things
that
we
always
mention
is
document
management.
We
were
a
small
group,
so
we
always
expect
you
know.
If
people
write
documents,
they
need
to
be
reviewed.
D
Please
volunteer
for
that,
and
and
do
it
and
put
your
comments
to
the
mailing
list,
even
though
there
are
just
comments
of
I
like
it
and
I
have
no
further
comments.
It
further
up
in
the
meeting
will
get
to
a
point
where
that
sometimes
fails.
What
are
the
particular
questions
that
we
have
for
this
meeting
is
document
Shepherd's.
D
D
We
had
a
jes
tchen
from
other
working
groups.
We're
looking
for
a
document
Shepard
during
adopting
a
document
for
the
working
group
would
be
a
good
idea
because
at
that
time
the
the
volunteer
that
is
shepherding
the
documents
also
is
aware
that
it
needs
to
follow
the
process.
While
the
document
goes
through
the
working
group,
what
we
are
sort
of
like
worrying,
whether
or
not
we
should
make
that
compulsory.
So
when
we
are
adopting
a
document
that
a
document
author
should
be
looking
for
a
document
Shepard.
D
E
Thank
you
for
this
is
Barry.
Thank
you
for
picking
on
one
of
my
real
pet
projects.
A
while
ago,
I
wrote
a
document
about
extended
document
shepherding
and
it
didn't.
It
didn't
go
anywhere
as
a
publication,
but
it's
in
the
working
group
chairs
wiki.
So
anybody
who
wants
to
look
at
that
can
go
to
the
working
group
chairs,
wiki,
which
is
accessible
to
everyone
and
read
that
and
it's
my
opinion
on
how
to
keep
documents
moving
along
by
active
shepherding
throughout
the
life
of
the
document.
So
thank
you
for
for
feeding
into
that.
E
I
agree
that
it's
a
good
idea
not
to
make
it
mandatory,
but
encouraging
that
to
happen
will
keep
documents
moving
and
remember,
as
you
should,
no
matter
how
you
Shepherd
a
document,
no
matter
when
it's
assigned
the
document.
Shepherd
job
is
not
just
to
write
the
Shepherd
right
up
and
then
disappear.
We
really
want
the
Shepherd
to
poke
people
and
make
sure
that
things
don't
get
forgotten,
which
often
happens
when
there
are
comments,
and
then
it
takes
months
to
resolve
them.
So,
thanks
and
having
said
that.
D
Only
thing
you
need
to
do
is
make
sure
that
all
the
comments
are
attended
to.
So
you
don't
have
to
understand.
What's
in
there,
you
only
have
to
know
what,
if
there
are
ten
comments
back,
that
ten
comments
have
been
responded
to
so
for
people
who
are
new
to
the
IDF,
a
great
opportunity
to
get
to
know
a
lot
of
people
and
get
introduced
to
the
process
of
the
IDF.
Okay.
Thank
you.
So
that's
about
dr.
document,
shepherding
yeah.
A
Okay,
so
one
last
thing
in
the
introductions
is
please
to
ask
everyone,
as
is
typical.
You
know
that
NomCom
is
here.
They
have
office
hours
or
folks
around.
You
know.
They
are
always
interested
in
comments
about
your
leadership,
in
this
case
some
area
directors,
so
Barry,
who
is
helpfully
being
our
jabber
scribe
here?
Let's
keep
that
in
mind.
You
know
all
four
come
it's
about:
America,
no,
but
in
all
seriousness
for
all
of
the
area,
directors,
and
even
those
who
are
who
are
standing
new
people
who
want
to
come
on
board.
A
The
NomCom
is
very
much
looking
for
comments
and
there
is
a
forum
that
you
can
go
to
on
the
website
and
then
on
website,
so
that
you
can
submit
comments
that
way
or
clearly
just
reach
out
to
anyone
who
you
see
with
a
NomCom
sticker
on
and
offer
to
offer
comments
about
it.
It's
a
important
part
of
our
process
and,
of
course,
as
always,
with
respect
to
the
chairs.
If
you
have
comments
about
your
chairs
here,
you're
welcome
to
to
stand
up
and
say
nice
things
at
the
microphone.
A
D
That
is
one
that
we
might
give
some
attention
to,
because
there
was
some
confusion
in
the
is
Gy.
An
informational
document
came
from
this
working
group.
We
have
some
problems
explaining
that
to
the
iesg,
because
usually
we
do
standard
strike
documents.
This
is,
of
course,
something
that's
typically
for
the
Ayana
EPP
registry,
where
we
allow
documentation
of
any
sort
for
proprietary
or
experimental
or
whatever
extensions
in
any
PP.
D
Normally,
the
process
for
an
informational
document
is
go
to
the
independent
document
screen,
but
this
one
we
reviewed
in
the
working
group
and
thus
it
has-
we
gave
it
a
tag
of
being
approved
as
an
informational
document
for
for
the
IANA
registry.
I,
don't
know
if
anybody
has
comments
on
that
knows
how
the
process
works.
I
sometimes
feel
the
need,
especially
when
talking
to
the
isg,
that
they
have
to
repeat
how
the
EPP
registry
EDI
naep
registry
has
been
set
up,
that
that
way
why
we
want
to
have
any
documentation.
D
The
the
initial
in
of
the
EPP
IANA
register
registry
was
that
we
were
looking
for
any
extension
that
was
out
there
and
we
wanted
to
have
it
documented,
and
we
wanted
to
take
that
as
a
sort
of
basis
of
looking,
which
ones
we
were
going
to
standardize
or
which
we
could
standardize
and
for
other
people
to
do
to
look
at
extensions
that
they
might
want
to
go
and
develop.
But
they're
all
already
was
something
that's
sort
of
looked
like
it.
F
G
A
For
the
so
I
see
John
Kang
here
in
the
back,
and
he
I
have
not
actually
had
a
chance
to
talk
to
him
about
this,
but
so
the
the
action
on
this
document
it
is
sitting
with
the
isg
and
Barry-
will
may
want
to
add
on
to
this
here
as
I
get
into
this.
So
the
idea
is,
there's
been
some
discussion
about
it
being
an
informational
document
as
a
working
group
product
and
the
suggestion
from
the
reference
here
would
be
to
make
it
an
informational
document
and
have
it
come
into
the
independent
stream.
A
Instead
of
being
a
working
group
product,
that's
all,
and
so
we
will
be
asking
John,
King
I'll
talk
to
you
more
about
it.
Afterwards,
hadn't
had
a
chance
to
catch
up
with
you
on
this,
as
we
put
all
this
together,
but
that's
the
action
will
go
on
this
document.
So
that's
the
way
it'll
proceed
from
this.
This
working
group
I
think
that's
it
then,
over.
E
To
the
mic
sorry
yeah:
this
is
Barry,
but
that's
basically
right
the
that
the
issue
isn't
completely
that
it's
informational.
That
would
be
reasonable
for
this
working
group
to
put
out
certain
informational
documents,
but
something
that
appears
to
be
defining
the
same
kind
of
thing.
That's
coming
out
of
this
working
group
as
proposed
standards,
but
this
one
being
informational
is
what
struck
the
iesg
as
odd,
and
it
will
definitely
go
much
more
smoothly
if
this
just
goes
through
the
independence
dream.
E
H
Some
number
of
years
ago
we
had
this
thing
called
our
RP
or
the
registry
registrar
protocol
that
was
used
in
you
know
the
network
solutions
and
Verisign
shared
registration
system
prior
to
the
existence
of
EPP,
and
there
was
a
suggestion
to
bring
that
to
the
ITF
and
standardizing
it
didn't
work
out.
Quite
that
way,
people
didn't
want
to
see
our
RP
standardized,
but
they
did
want
to
see
it
documented
right
and
anyway.
So
the
long
and
short
of
it
is
one
of
the
suggestions
was
to
make
it
clear
that
this
is.
H
You
know
an
informational
thing
coming
out
of
NSI
and/or
Verisign
was,
in
the
titles,
say
the
NSI
registry
registrar
protocol,
which
eventually
became
of
the
Verisign
register
protocol.
So
one
suggestion
here
consider
modifying
the
title.
You
know
to
something
like
the
CN
nick
EPP
domain
mapping
extension
blah
blah
blah
I
I.
Think
that'll
make
it
clear
that
you
know
hey.
This
is
where
it's
coming
from,
and
it
helps
to
explain
why
this
is
an
informational
thing,
as
opposed
to
something
that
is
on
the
standard,
strap
just.
I
For
clear
is
a
document
a
state
hearse,
so
I
mean
maybe
a
lot
of
years
already
a
lot
of
years
work
and
this
document.
So
every
new
version,
I
singer,
is
for
standard
tracker.
So
after
working
group
discussion,
so
this
is
it
just
for
a
few
registries,
mainly
the
Chinese
domain
name
is
really.
The
icing
is
not
all
not
just
for
its
scenic
oscillator
low
spec
admission,
as
actually
is
a
for
many
Chinese
dominated
registry,
for
example.
I
I
This
document
I
think
there's
a
few
registry,
not
not
only
for
Seneca,
so
because
we
have
all
a
long,
long,
hard
workers
a
lot
of
years
worker
is
this
working
group
were
so
weak
I
like
to
continue
as
a
looking
follow
the
working
working
working
for
all
document
as
they
follow
as
the
revelation.
Thank
you.
E
D
So
so
I
understand
that
you
know
it's
used
by
multiple
registries,
but
it's
not
used
by
all
registries.
We
had,
of
course,
in
preparation
for
this
draft
also
a
bundling
buff
where
there
could
also
not
be.
There
was
also
no
consensus
of
what
sort
of
bundling
was
appropriate
and
could
fit
all,
and
one
of
the
result
of
that
was
okay.
We
are
going
to
see
if
we
can
get
the
strict,
bundling
variants
documented
for
EPT.
I
So
as
Singapore
for
whether
we
initial
discussion,
we
have
a
lot
of
maybe
pompano
means
situations,
so
the
working
group
decides
there's
are
many
annalisa
tourism.
Is
there
the
street
puniness
great
situation
and
under
some
are
relaxed
for
the
Pannonian
secretion.
So
this
this
is
mainly
focus
on
straight
upon
the
funding,
funnily
registration,
so
I
think
maybe
it's
it's
already
used
by
Chinese
domain
name,
community
or
registry,
or
a
lot
of
rituals,
so
in
future
may
also
come
extent
who
used
by
other
name
asked
he
names.
I
D
Okay,
then
we
move
on
to
documents
in
working
group
last
call
which
are
two
documents.
Actually
it's
the
data
escrow
and
the
Deanery
object
mapping
documents
these
could
have
been
outside
out
of
the
last
call
already,
but
there
were
last-minute
changes
that
needed
to
be
made
to
the
DNA
our
object,
mapping
documents,
and
we
put
that
in
this
second
working
group
last
call
and
we
didn't
get
so
far.
D
We
only
got
two
responses
of
people
saying:
okay,
we
approve
this
document
in
working
as
call
this
is
not
enough
folks,
we
really
need
people
to
react
also
to
a
second
working
with
last
call
and
put
a
comment
on
the
mailing
this
that
you
agree.
That
change
is
in
the
second
working
with
past
call
or
not
substantive,
or
that
way
are
they
are
okay.
If
we
don't
get
any
response
to
this,
this
is
not
going
to
be
published.
J
I'm
Jim
gold
from
Verisign
I'm.
The
document
shepherd
for
the
registry
data
escrow
specification
and
in
my
responsibility,
is
dot
and
Shepherd
I
did
a
detailed
review
of
the
draft
and
I
have
some.
What
I
feel
our
editorial
changes
to
the
graph,
but
I
really
want
feedback
from
the
working
group
to
confirm
that
specifically
and
I'm
going
to
post
it's
the
list
by
the
way.
I
just
have
some
highlights
here.
J
One
item
is
associated
with
since
the
graph
refers
to
registry
registrar.
Those
are
ignore,
see
that
defines
those
terms
to
refer
to
those
that
RFC
also
in
the
examples
as
dr.
Shepherd
I
need
to
validate
the
examples,
and
the
issue
was:
is
that
there's
use
of
dot
dot
dot
in
the
example?
So
what
I
did
was
I
went
in
and
created
full
examples
for
each
of
the
concrete
types
supported
by
the
draft.
J
In
doing
so,
I
found
errors
in
the
example,
and
my
recommendation
was
to
include
those
examples
in
the
draft
for
clarity
as
I
got
down
to
the
XML
schema
I
noticed
that
the
XML
schema
was
importing
the
EPP
com
XML
schema,
which
in
essence
created
a
hard
dependency
to
the
EPP
RFC,
which
was
was
concerning
to
me,
but
then,
when
I
dug
a
little
deeper,
it
wound
up
where
the
data
type
that
was
used
that
use
that
reference
was
actually
not
being
used
anywhere
within
the
draft.
So
in
essence,
was
just
hanging
out
there.
J
So
my
recommendation
is
and
I'll
put
this
on
the
list.
The
the
data
type
RR
type
is
not
being
referenced,
I,
don't
believe
that
will
have
any
issue
related
to
removing
it
and
any
associated
the
import
of
the
EP
become
schema
into
this
schema.
So
in
essence,
I'll
be
looking
for
the
working
group
to
confirm
that,
but
my
recommendation
is
to
go
ahead
and
remove
that
and
then
one
final
element
is
associated
with
supporting
different
types
of
deposits.
So
we
have
a
scenario
where,
for
the
registries,
the
ICANN
accredited
registries,
we
need
to
provide
a.
J
Let's
call
Brda
that
uses
the
data
escrow
graphs,
that's
really
not
data
escrow
they're,
really
not
so
we
had
some
discussion
me
and
the
document
editor
to
be
able
to
make
the
drafts
be
explicit,
related
to
the
fact
that
this
is
a
different
type
of
deposit.
It's
not
needed
escrow,
it's
a
form
of
deposit,
and
so
the
decision
was
or
the
recommendation
was,
was
to
not
to
change
the
types
to
find
it
in
the
base
draft,
but
actually
put
into
the
mapping
draft
a
tag
or
an
indicator.
J
J
Well,
yeah,
well
the
concern
and
you
could
speak
up
to
it
as
well.
Is
that
fact
that
in
changing
the
schema
or
removing
and
helmet
from
the
scheme
and
there's
a
concern
related
to
whether
or
not
that
would
cause
any
interoperability
issues,
and
that,
if
that
were
the
case,
we
may
need
to
be
able
to
reach
out
to
a
broader
set
of
folks
to
ensure
that
in
fact
is
not
an
impact.
Does
that
make
sense?
Okay,.
A
So
let
me
just
I'll
add
to
that
a
lot
more
context,
I
guess
so:
Jim
Calvin
speaking
and
not
wearing
it.
The
chairs
had
here.
These
documents
have
some
history
and
in
fact
one
of
the
issues
here
is
that
they
are
broadly
implemented
in
the
gTLD
market.
You
know
amongst
registries
and
registrar's,
so
the
documents
have
been
required
of
gTLD
registries
and
and
some
registrar's
here
since
the
last
round
of
new
gTLDs.
A
So
the
issue
here
is
to
make
sure
that
whatever
we
do,
we
don't
change
these
documents
in
a
way
that
creates
an
interoperability
issue
or
any
or
that
they
remain
backwards
compatible.
So,
in
fact,
what
Jim
Ghul
was
just
talking
about
with
wanting
to
change
the
mapping
document
dad
an
indicator
in
it,
he's
going
to
go
back
and
and
think
about
that
the
best
way
to
do
that
so
that
the
document
remains
backwards
compatible
just
in
case,
and
so
that's
just
something
we're
bringing
to
the
attention
of
this
group.
A
You
know
the
reality
is
we're
gonna
hear
more
later
about
a
joint
meeting
with
with
tech,
ops.
You
know
that
is
sort
of
our
opportunity
to
get
broader
exposure
of
some
of
our
work
with
more
folks
in
this
industry,
and
we're
gonna
see
some
examples
of
work
that
we're
gonna
bring
from
there
to
here.
But
that's
the
context
that's
going
on
here,
so
you
know
Jim
identified
some
some.
A
You
know
issues
that
we
ought
to
clean
up
and
just
make
stable
and
and
clean
I
guess
is
the
right
word,
but
do
that
in
a
way
that
doesn't
impact
existing
implementations
as
much
as
possible.
So
that's
the
goal
and
we'll
bring
this
to
the
mailing
list
for
one
last
look
when
we
got
it
all
settled
and
have
a
suggestion
for
doing
all
of
that,
thanks.
A
D
J
K
B
K
L
D
That's
all
this
way,
that's
why
I
asked
the
question:
no,
no,
the
India
object.
Mapping
that
one
is
in
second
worker
group
last
call
if
there
are
changes
to
that
documents
which
are
purely
editorial,
then
of
course
it
stays
that
way,
but
I
understand
from
from
James
now
that
the
data
escort
document
is
also
going
through
a
new
revision,
and
so
we
are
going
to
place
another
second
work,
that's
all
for
that
one
as
well,
so.
A
For
both
documents
they
will,
they
will
get
a
a
Reb
in
the
version
number
right.
As
long
as
the
changes
are
editorial
and
they
don't
affect
interoperability
in
any
way,
it
will
not
be
another
working
group
last
call
it
is
that
revised
version,
taking
into
account
working
last
call
comments
that
will
then
go
forward
and
be
published,
but
if
there
is
a
technical,
substantive
change,
then
we
will
have
to
do
a
working
group
last
call,
although
hopefully
we
can
make
it
relatively
short-
will
see.
M
D
Okay,
so
that
concludes
our
current
document
status
of
at
least
anything.
That's
we're
not
working
on
anymore
for
an
overview.
This
is
our
milestone.
Review
of
the
milestones
that
we
are
supposed
to
be
doing
or
have
done,
you'll
see
a
lot
of
the
lot
of
them
already
done.
We
move
on
to
the
existing
work
now
and
we
have
Mario's
going
to
present
something
wrong
the
the
art
of
documents.
O
O
Lots
of
these
changes
resulted
from
the
feedback
provided
by
Tamera
zone.
Thank
you,
Tom
for
your
standard
review.
It
was
very,
very
appreciated.
Let's
start
with
the
draft
about
partial
response
in
in
adapt,
businesslike
to
version
have
been
published
since
last
meeting
in
version
0-3,
a
diversion,
zerotree
added
the
a
unique
own
name
field
in
the
IDF
you
set
when
returned
a
domain
or
name
server,
is
an
ibn
and
last
the
currently
activation.
O
O
O
Okay,
next
try
the
next
slide,
please.
In
this
case,
free
version
have
been
plug
published
since
July
in
the
the
bathrooms
zero
for
replaced,
the
LDH
name.
We
named
among
the
sorting
properties,
the
name
certain
property
is
mapped
onto
the
combination
of
LDH
name
and
único
name.
This
is
because
in
enid
up
there
exists
two
different
elements:
different
views
of
the
same
data
and
the
this
data
is
mapped
on
the
same
underlying
database
field.
The
unicorn
name
value
must
be
taken
while
sorting
when
the
unique
own
name
is
missing.
O
O
In
brief,
this
means
that
the
JS
of
strings
must
be
sorted
according
to
the
left,
less
psychographic
order
and
JSON
numbers
must
be
sorted
according
to
lessen
the
numerical
order,
with
the
only
exception
of
IP
addresses,
which
better
clarified
the
inversion.
Z05
the
j
card,
so
test
parameters
must
be
ignored
for
the
purpose
of
this
sorting
capability
and
when
more
than
one
value
is
the
sorting
will
be
applied
to
the
value
identified
by
a
preference
information.
O
It
could
be,
for
example,
the
parameter
jacquard
parameter.
If
a
preference
information
is
missing,
the
sorting
will
be
applied
to
the
to
the
first
value
of
the
collection.
The
0-5
version
clarified.
The
certain
logic
on
IP
addresses
IP
addresses
must
be
sorted
based
on
the
numeric
conversion,
rather
than
they
they
be
JSON
string
the
value
it
clarified
as
well.
O
The
mapping
between
the
certain
properties
and
the
other
fields,
each
other
provider,
may
define
other
certain
probabilities
than
those
providing
this
document,
as
well
as
it
may
map
those
sorting
properties
on
different
location,
for
example,
due
to
a
different
presentation
of
the
contact
representation.
This
is
the
subject
of
my
next
presentation
here
in
this
session.
O
Important
thing
to
evaluate
for
next
version
is
how
to
implement
vaccination
when
links
can
be
used.
For
example,
this
is
the
case
of
the
request
submitted
via
HTTP
POST.
Currently,
this
is
not
allowed
in
the
inaudible,
but
it
could
be
in
the
future
if
we
work,
for
example,
submit
complex
query,
including
lots
of
predicates
joining
the
by
boolean
operators,
the
current
structure
parameter
and
element
that
element
doesn't
support
this
case.
O
O
O
O
They
could
be
a
piece
or
out
gnomes
if
we
think
that
entities
are
in
relationship
with
any
other
object
in
adapt
role
must
be
one
of
the
rules
described
in
section
ten
point,
two
point:
four
or
elf
c74
a
tree
for
role,
independent
searches,
the
value
entity,
generic
value
entity
must
be
used
and
property
is
the
entity
property
to
be
used
in
matching
the
search
pattern.
A
predefined
list
of
properties
includes
format,
name
and
only
mail,
city,
country
and
country
code.
K
B
D
O
O
This
solution
in
the
in
the
ended
up
service
currently
I,
don't
know
any
other
implementation
about
these
documents.
Obviously,
in
addition
to
the
ite
at
the
server,
if
there
is,
if
there
are
any
other
implementation,
I
am
happy
to
to
to
contribute
to
help
anyone
who
is
willing
to
implement
these
solutions.
L
Tom
Harrison
ethnic
I
just
had
one
comment
on
the
reverse
search
document.
The
sorting
and
paging
document
appears
to
allow
or
does
allow
our
customizable
mapping
of
the
of
the
field,
whereas
the
reverse
search
document
appears
to
be
quite
prescriptive
about
what
fields
have
to
be
used
for
the
reverse,
search
I.
Think
it's
I
think
your
intent
is
to
allow
that
to
be
service,
specific
for
reverse
search
as
well,
so
I
think
it's
just
a
terminology
thing
in
the
job,
just
to
clarify
that
service
can
do
what
they
want
with
the
reverse
search.
Yes,.
K
Alex
meal
for
anecdote,
a
key
just
as
a
heads
up.
We
might
start
looking
into
implementing
an
art
at
servant
early
2020,
so
we
might
not
have
time
this
year
to
start
working
on
it,
but
but
it's
definitely
going
to
happen
in
the
first
quarter
of
next
year.
So
it's
probably
too
late
for
the
documents.
But
this
is
a
heads
up.
So.
O
And
I
think
that
we
must
have
more
time
to
evaluate
these
documents
because,
for
example,
in
the
final
report
for
add
a
pilot
project
state
that
most
of
for
most
of
the
submitted
queries
are
lookup
queries
rather
than
search
queries.
So
I
think
that
now
they
are
top
implementers
are
knowing
adapt
better.
So
they
can
evaluate
the
if,
if
this
solution
can
contribute
to
make
the
they
are
top
service
more
efficient,
so
because
it
depends
on
the
obviously
on
the
service
provided
by
the
other
service.
O
O
Maybe
there
are
some
new
other
service
implementation.
Try
to
implement,
search
queries
in
efficient
way,
so
probably
they
have
to
to
to
implement
sorting
and
paging,
and
if
and
partial
response,
if
they
want
to
make
they
implementation
more
efficient
but
reverse
search
is
another
is
a
different
situation,
because
it
depends
on
the
service
that
they
adopt
servic
want
to
provide
to
the
end-user
or
register
I,
don't
know,
for
example,
we
annoy
dot
dot
ID.
We
want
to
provide
our
register
to
with
the
capability
to
reverse
search
on
their
own
domains.
O
O
O
O
P
B
P
B
O
O
In
the,
if
we,
if
I
look
to
the
implementation,
the
dotted
implementation
that
we
we
want
to
provide
this
discovery
to
our
registers,
they
are
legitimated
to
to
see
the
personal
information
of
their
own
contacts,
not
the
info
personal
information
of
other
register
console
contacts.
Obviously-
and
this
is
the
the
principle
aspiring
this
dissolution-
the.
O
O
P
A
A
P
A
I'm
sorry
I
want
to
jump
in
here
as
chair
and
say
that
I
don't
want
to
fall
into
the
discussion.
All
the
privacy
discussion
we
had
last
time.
It
is
true,
actually
I,
do
share
your
concern
to
what
you're
saying
about
the
privacy
considerations
as
written,
but
let
me
suggest
that
we
take
that
to
the
list.
Look
update
that
that
side
of
things
want
to
give
Alex
a
chance
here
to
have
a
last
word
and
then
I
want
to
drive
towards
a
milestone
discussion.
Yes,.
K
O
N
N
C
K
Out
whether
they
are
compatible
yes,
interoperable
I
would
say
between
science
and
service
and
also
like
people
like
me,
yeah
who,
like
looking
into
implementing
that
that
they
would
maybe
try
to
do
a
sort
of
review
on
that
and
and
at
least
any
potential
implementation
issues
they
would
have.
And
after
that
we
could
pray
really
like
working
through
blast.
Call
it
yeah
III,
don't
remember!
You
have
implementation
status
section
in
the
document.
Yes,
perfect
good,
so
maybe
up
that
date,
update
that
and
and
and
get
after.
O
D
D
Q
Q
In
the
and
speaking
to
things
that
offer
example,
one
in
the
are
tab
pilot
working
group
back
over
the
summer
mark
lon
mark
blonde
Shay's
work
on
the
client-side
was
instrumental
in
driving
a
lot
of
clarity
and
then
I'll.
Note
the
and
I
admit
that
I
haven't
been
following
this
this
closely.
But
from
what
you
said
and
Tom
Harrison's
work
was
instrumental
in
helping
to.
Q
O
O
D
List
and
if
anything
is
be
done,
please
do
it
got
another
list.
I
do
tournament,
misery,
ok,
next
presentation
existing
work,
and
this
is
actually
something
that
is
not
on
our
milestones
list,
but
it
came
back
Gustavo.
So
if
you
could,
please
also
put
a
little
history
on
status
of
this
document.
Please
sure.
M
Just
awaken
next
slide,
please.
So
this
is
a
really
old
draft.
It
was
polishing
2013,
and
this
draft
describes
the
services
that
are
provided
by
the
tmdb,
which
is
the
tremor
database,
something
that
was
created
for
the
icon.
Tremor
clean
house
and
registries
and
registers
use
these
drugs
to
implement
the
integrations
with
those
services.
M
When
the
first
version
was
published,
we
already
had
like
several
conversations
with
trace
trees
and
registers
regarding
this,
so
the
first
version
was
quite
mature
and
stable.
There
were
no
major
changes
since
May
2014.
The
intended
status
of
this
graph
is
informational,
I,
don't
know
if
that's
going
to
be
an
issue
with
the
going
this
being
and
working
or
working
group
document,
or
we
need
to
go
to
independent,
independent
tracks
and
I
mean
that's.
M
That's
a
good
question
right,
as
I
mentioned
before,
this
draft
has
been
implemented
by
registries
registrar's
and
Clearing
House
in
the
case
of
the
GT
Li
space
looks
like
this
back
in
2016.
The
idea
was
to
push
these
as
I
never
seen.
The
draft
was
adopted
by
the
EPP
extension
working
group,
which
is
the
working
group
that
precedes
this
working
group.
M
On
the
last
phase
of
the
draft,
we
received
some
comments
from
Patrick
and
based
on
those
comments.
We
had
several
well,
we
had
meetings
with
Patrick
and
we
modified
that
document.
That
is
there
that
document
I
can
document.
It's
not
related
to
this
draft.
Well,
it's
linked
from
this
graph,
but
it's
not
like
like
a
normative
reference,
but
I
don't
remember
so,
but
the
end
of
the
day
we
modified
that
document.
We
verified
some
things
within
the
Clearinghouse
and
everything
work
out,
so
we're
good.
The
Nexus
lied
to
the
best
of
my
knowledge.
M
M
This
draft
is
linked
from
several
legal
contracts,
so
we
really
want
to
have
unstable
reference
because
it
has
been
expired
for
some
time
in
the
past
and
needs.
May
be
not
a
good
idea
to
have
an
expired
draft
link
from
a
legal
contract.
Nexus
light
and
that's
it
I
mean
I,
don't
know
if
you
have
any
questions.
A
Over
the
answered
questions
and
we
have
a
questions:
okay,
so
Jim
Galvin
not
wearing
a
chair
hat.
So
this
this
document,
like
the
data
escrow
documents,
has
a
fair
amount
of
history
in
existence,
so
it
also
has
fairly
broad
deployment
but
documenting
it
was
in
an
issue
because,
from
a
technical
point
of
view,
it
was
just
missing
the
ICANN
side
who
was
missing
the
policy
side
of
it,
what
it
needed
to
look
like,
and
some
we
needed
some
changes
on
that
side
in
order
for
this
document
to
be
considered
stable.
A
We
would
we're
gonna,
seek
just
to
make
sure
that
Patrick
wants
to
relieve
his
his
objection
that
all
of
that
has
been
satisfied
and
in
this
document,
like
the
escrow
documents
again
well,
this
is
actually
in
better
shape
because
there's
been
no
changes
to
the
document.
It's
just
that
it
now
has
a
context
in
which
to
live,
which
is
accurate
and
correct
and
functioning
with
the
matching
rules
defined
by
by
ICANN.
A
A
R
A
N
A
We
do
have
an
issue
about
implementation
and
how
much
further
we
want
to
push
on
implementation
before
the
working
group
agrees
for
them
to
go
forward
so
I'm
thinking
that
one
way
to
to
force
that
question
is
to
suggest
that
we
we
move.
Those
into
working
group
last
call
so
that
we
can
have
people
comment
explicitly
that
they
don't
want
them
to
go
forward
without
a
particular
action.
I'm
thinking
that
we
just
want
to
find
a
way
to
force
the
working
group
to
respond
and
and
and
react
to
these
documents.
A
And
then,
if
there
are
implementation
concerns,
people
can
speak
to
that.
And
then
we
can,
you
know,
decide
at
the
end
of
that
that
we're
going
to
wait
for
another
period
and
do
that.
I
would
like
to
suggest
that
we
actually
put
those
two
into
working
group
last
call
and
we'll
see
how
that
plays
out.
If
it
ends
up
that
we
want
to
hold
them
back,
because
we
want
more
implementation.
A
Experience
then
we'll
have
to
turn
that
into
updating
the
milestones
with
respect
to
those
two
documents,
and
one
option
might
be
that
we
not
actually
have
a
milestone
for
them.
Okay
and
you'll
see
why
that
might
be
relevant
as
we
get
into
new
work
and
we
start
moving
forward
or
we
might
just
update
the
milestones,
but
we
can
make
that
decision
later.
So
a
working
group
last
call
for
those
two
documents
following
this
IEF
is:
where
we'll
go
with
those
the
reverse
searching
document:
I
get
the
sense
that
there's
still
work
to
be
done
there.
A
We
don't
think
that
that
is
as
stable
as
the
other
two.
So
what
we
need
to
think
about
here
is
what
to
move
the
milestone
to,
since
it
really
was
due
now
and
I.
Don't
know
if
Mary,
oh,
if
you
want
to
say
anything
about
that
now
or
we
can
take
that
to
the
list.
We
can
just
see
wick
listening
to
my
co-chair
here
saying:
let's
just
take
it
to
the
list.
We
should
make
a
decision
about
how
far
we
want
to
push
out
the
milestone
for
that.
A
So
we'll
try
to
pass
that
message
on
to
the
working
group
and
people
can
take
some
time
to
think
about
what
they
want
to
do
there.
Okay,
open
ID,
we'll
just
leave
a
loan
for
right
now,
although
maybe
I
don't
know
Scott.
If
you
want
to
say
anything
about
it
or
not,
you
don't
have
to
feel
obligated
to,
but
you're
standing
up
so
please
go
ahead.
Sure
Scott
home
back
with.
H
Respect
to
this
document,
I
think
the
protocol
piece
is
actually
pretty
solid,
it
hasn't
changed
much
in
the
last
year
or
so,
and
in
fact
you
know
the
different
machination
zuv
people
who
have
looked
at
it
like
in
the
IKEA
context.
In
particular,
you
know,
while
they
move
the
bits
and
pieces
around
they're
still
basically
using
the
same
protocol
and
so
I
feel
pretty
confident
about
that.
I
am
much
less
confident
in
whether
or
not
I
got
the
Ayana
registry
bits
correct.
You
may
recall
there's
a
section
in
there.
We
come
registering
ooofff
claims.
H
You
know
that
are
used
to
help
document,
attributes
of
appropriate
identities
and
there's
a
lot
of
dependence
there
on
what
comes
out
of
I
cans.
You
know
expedited
policy
development
process.
You
know
for
anyway
lots
of
acronyms
there
I
I
think
it's
something
we
have
to
make
a
call.
I
could
pull
out
the
Ayana
registry
bits
and
just
say:
hey!
Look
when
I
can
get
to
texting,
acts
act
together
there.
H
Those
claims
can
be
registered,
you
know,
and
then
the
protocol
piece
progresses
independently
or
we
just
hold
on
a
little
bit
longer
and
try
to
capture
the
bits
we
know
will
be
necessary.
You
know
to
meet
ICANN's
needs
and
I
guess
I'm
kind
of
leaning
towards
let's
just
hold
on
a
little
bit.
They
seem
to
be
making
progress,
and
you
know
who
knows
six
months
from
now.
They
may
actually
have
some
outputs.
A
So,
thank
you
for
that
I
mean
speaking
for
myself.
I
am
inclined
to
not
make
a
milestone
change
at
the
moment,
I
mean
on
the
ICANN
side,
there's
a
certain
expectation
of
something
to
appear
relatively
soon
that
the
our
deaf
working
group
on
that
side
can
actually
do
something
with
and
we'll
have
a
better
sense
by
the
time
we
get
around
to
the
next
ITF
meeting.
A
D
G
A
So
this
is
me
presenting
as
myself,
not
as
co-chair
here,
but
go
to
the
next
slide.
So
we
did
something
new
and
interesting
that
we've
sort
of
mentioned
this
a
few
times
here.
But
let's
try
to
be
very
clear
and
specific
here
about
the
relationship.
What
was
going
on
the
tech
ops
is
a
Technical
Operations
Group
in
in
ICANN,
and
it
is
comprised
of
essentially
technical
representation
from
registries
and
registrar's
on
the
gTLD
side
and
there's
quite
a
lot
of
them
in
there,
and
you
know,
obviously
many
more
of
them
than
err
that
are
here.
A
A
We
we
believe
that
we
have
gotten
many
more
of
them
to
join
the
mailing
list,
they're
not
likely
to
appear
physically
at
an
ITF
meeting,
but
they
will
be
on
the
mailing
list
and
we'll
be
able
to
move
documents
forward
and
participate
in
that
way.
So
the
goal
at
the
inter
meeting
was
to
review
those
14
potential
documents
and
you
know
think
about
what
they
would
consider
the
priority
and
how
they
wanted
to
approach
them.
And
then
you
know
come
here
to
seek
adoption.
A
Think
of
the
tech
ops
group,
as
a
design
team
in
an
IETF
context,
is
sort
of
the
way
to
view
that
body
of
people
and
the
work
that
they
do
and
then
to
bring
those
documents
to
this
group
and
consider
adoption
here
and
move
them
along
on
the
IETF
side.
So
that's
sort
of
the
relationship
and
what's
going
on
there,
we
conducted
that
joint
meeting
under
the
ITF
note.
Well
so
that
was
exposed
there
and
in
that
group,
and
you
know
everybody
aligned
with
that.
So
that
was
a
good
thing.
A
It's
worth
noting
that,
in
the
middle
of
the
slide,
is
a
best
practice,
not
actually
that
should
be
best.
No,
it
is
it's
best
practice
domains
website.
There
is
a
group
of
registrar's
that
have
created
a
website.
All
14
of
these
documents,
in
their
original
form
from
that
group
are
on
that
website,
and
so
they
had
created
a
place
where
they
had
put
things
in
fact.
Have
those
documents
are
all
produced
in
our
internet
draft
format
for
that
matter,
and
that's
where
they
all
work
and
having
that
discussion
so
good
Alex.
K
A
Enough
I
I
take
your
point
and
let
me
yeah
you're
right
I
was
pretty
freewheeling
with
saying
the
word
standard
I've
been
called
on
that
before,
in
fact,
just
earlier
this
morning,
before
this
meeting
so
yeah,
we
need
to
be
a
little
more
careful
about
use
of
that
word.
It
may
be
that
some
of
these
things
really
become
informational
documents,
for
example,
as
opposed
to
to
a
standard
and
I
do
need
to
be
much
more
careful
about
that
in
the
IETF
context.
A
A
So
this
is
a
quick
rundown
of
what
we
talked
about
there
and
I
will
touch
on
these
briefly
and
and
I'll
spend
actually
a
bit
more
time
on
the
last
one.
The
14th
can
actually
be
brought
together
and
categorized
into
these
five
documents
in
these
five
areas.
So
registry
mapping,
we
really
only
referenced
it
in
the
in
the
in
the
interim
meeting
registry
mapping.
As
you
know
has
actually
been
work
that
has
been
moving
forward
slowly
under
the
auspices
of
this
working
group.
A
It's
not
really
an
adopted
document
in
this
working
group,
but
there
is
an
internet
draft
which
is
out
there
and
there
is
a
small
set
of
people
who
have
been
progressing.
That
document
in
particular,
you
know
Roger
Carney
and
has
been
leading
some
interim
meetings
along
the
way
here.
We've
had
several
in
trying
to
advance
this
work.
It's
not
yet
ready
to
be
adopted
by
the
working
group
or
to
seek
adoption
of
it,
but
that
work
is
proceeding
so
we're
just
gonna
leave
that
one
where
it
is
at
the
moment.
A
The
secure
authentication
is
notification
in
unhandled,
namespaces
have
all
been
documents
here.
The
SecureAuth
have
all
been
internet
drafts.
The
auth
info
document
got
quite
a
lot
of
discussion
at
the
tech,
ops,
meeting
and
I
think
there
is
a
revision
of
that
document,
which
will
be
produced
based
on
comments
that
were
received
there.
But
all
three
of
these
are
now
in
a
relatively
stable
state
and
they
will.
A
We
expect
that
we
will
seek
working
group
adoption
for
all
three
of
these
documents,
or
at
least
the
next
version
of
secure
auth
info
transfer
and
then
the
other
two
which
have
existed
for
some
time.
We've
had
some
discussions
about
them
in
this
working
group
in
the
working
group
meetings
and
we
will.
A
The
registry
registrar
reporting
document.
As
you
know,
we
have
we've
had
discussions
here
about
an
internet
draft,
as
you
can
see
the
reference
on
there.
The
data
set
draft,
the
dataset
file
format
draft
and
in
particular,
the
registry
register.
Our
mapping
was
a
new
proposal
concept
which
myself
and
and
my
colleague
who's
actually
out
there
remotely
Joseph.
He
had
brought
to
the
tech
ops
group
to
have
some
discussion
about
it
and
what
I'd
like
to
do
here
is
just
to
make
a
presentation
of
a
revised
set
of
slides.
A
It's
just
a
few
slides
to
sort
of
talk
about
the
concept
and
expose
it
here
in
this
group,
so
that
everyone
has
seen
it
once
we
don't
have
a
document.
That's
an
internet
draft,
that's
been
published,
so
we're
not
going
to
immediately
seek
working
from
adoption
on
this
thing,
but
it
is
work
that
we
expected
sometime
in
the
not-too-distant
future.
There'll
be
another
internet
draft,
and
so
there'll
be
more
discussion
about
this.
A
As
as
we
move
it
forward,
I
expect
that
it
will
get
a
good
deal
more
discussion
in
the
tech,
ops
group
in
particular,
because
the
registrar's
and
and
the
registries
there
will
want
to
talk
about.
You
know
what
that
document
looks
like
and
what
its
relationship
with
the
dataset
file
format
document
is,
so
that
we
can
bring
both
of
those
together
and
decide
what
to
move
forward
in
this
working
group
and
seek
working
group
adoption
on
those
things.
A
T
From
I
panic,
so
I
would
I'd
like
to
start
by
saying
I
think
you
have
a
really
good
sense
of
the
momentum
in
your
agenda
and
you've
done
a
good
job
of
a
reduction
of
what
needs
to
be
done.
You've
got
a
coach
and
story.
Let's
do
this
work
so
viewed
from
10,000
feet.
This
is
good.
You
have
a
backlog
of
work,
you're.
Looking
at
your
adjustments
and
pace.
This
is
what
you're
going
to
carry
forward
in
your
stream.
T
T
The
business
function,
registrar
registry
function
compared
to
the
pub
service
of
our
that
we
don't
actually
get
mind,
share
and
is
probably
a
function
of
the
nature
of
our
work
and
it's
not
a
comment
more
than
a
whinge,
but
essentially
we
have
very
little
mind
share
in
this
room
and
you're
building
a
lot
of
work.
That's
about
registry
registrar,
business,
the
business,
an
important
function
and
I'm
sitting
over
here,
saying
where's
our
mind
share
to
move
forward
in
the
public,
our
dad
commitment.
T
We
we
don't
have
this
investment
in
time
and
energy
coming
to
say,
look
at
the
body
of
work.
Let's
do
this.
This
is
our
stream.
Your
stream
is
progressing.
Our
stream
is
paddling
a
little
slower.
It
just
feels
strange.
I,
don't
think
this
is
a
problem.
You
can
fix.
I,
guess,
I'm,
just
whinging
it
world
rail
rail
rage
against
the
night
rage
against
the
dying
of
the
light.
E
A
E
E
B
A
So,
just
putting
on
a
chairs
hat
for
a
moment
recall
that
this
working
group
essentially
has
two
work
streams.
If
you
want
to
think
of
it
that
way,
we
have
an
our
DAP
work
stream
and
a
registration
services,
work
stream
and
the
our
DAP
work
stream
has
just
been
focused
on
Mario's
documents,
primarily
the
ones
that
we
were
we
were
just
talking
about,
but
we
will
see
shortly
that
there
is
going
to
be
a
new
work
item.
A
That's
going
to
be
proposed
when
we,
when
we
get
there
well,
actually
it's
not
even
on
the
slides
on
the
agenda.
It's
gonna
come
up
under
any
other
business.
For
that
matter,
I
just
happen
to
have
a
heads
up
that
is
coming,
so
there
will
be
some
some
movement
there,
but
you're
right
George,
you
know
I
mean
we
have
to
work
streams,
and
so
we
have
to
develop
and
and
move
along
work
in
both
of
those
spaces
and
and
the
chairs
do
know
that
responsibility
and
accept
that
and
we're
certainly
paying
attention
to
that
detail.
A
Sorry,
that's
concern.
Okay.
Let
me
go
back
to
just
being
myself
here
for
the
moment
and
we'll
go
to
the
slides
on
the
registry,
registrar
reporting
and,
while
he's
working,
to
bring
up
those
slides.
So
again,
this
is
just
an
introduction
of
a
of
a
of
a
concept.
There
are
between
registries
and
registrar's.
They
do
communicate.
A
Now,
to
allow
some
flexibility
in
all
of
this-
that's
really
what
this
is.
This
is
about
so
for
here
this
is
just
about
presenting
a
concept
which
was
presented
there.
It
half
of
this
was
reasonably
well
received
and
seemed
to
get
a
good
traction
and
support,
and
then
there's
a
set
of
issues
that
were
kind
of
set
aside
as
still
discussion,
points
and
I
will
separate
those
two
here
as
we're
going
through
these
slides
and
then
we'll
see
where
we
are
so.
A
This
is,
if
anybody
has
any
comments
about
this,
we
certainly
would
welcome
all
that
input,
but
next
steps
here
again
are
that
this
will
just
continue
in
its
design
effort
for
right
now.
So
this
is
just
you
know.
What
do
you
think?
You've
obviously
never
seen
this
before,
because
there's
no
document,
except
for
the
slides
that
exist,
but
any
reactions
and
you'll
now
have
the
slides,
and
we
can
continue
some
discussion
on
the
mailing
list
about
this
too.
A
So
with
that
as
an
opener,
let's
go
to
the
next
slide,
so
this
is
some
kind
of
a
an
example.
If
you
were
to
look
at
the
best
practice
domain
site,
you
would
see
that
there
is
a
specification,
for
you
know
at
least
these
three
reports
transaction
report,
a
premium
name,
support
at
the
main
info
report.
There's
some
specifications
there
and
you
know
this
is
what
these
things
look
like.
A
A
You
know,
maybe
stable
is
a
better
word
here
than
saying
the
static,
but
the
format
of
the
report
is
is
standardized
or
that
there
is
a
there's,
a
framework
that
there's
a
known
mechanism
for
understanding
the
report
so
rather
than
the
registry
just
being
able
to
unilaterally
decide
what
something
looks
like
there's,
there's
a
framework
and
a
and
a
stability
about
what
that
reports
is
likely
to
look
like
for
registrar's
to
consume
them.
Okay,
so
to
facilitate
that
and
provide
a
bit
of
a
more
stable
mechanism
for
that
communication.
A
Obviously
we
still
want
the
syntax
of
the
elements
in
the
report
to
be
standardized.
We
don't
we
don't
want
people
just
inventing
anything
that
they
can
put
in
these
reports
and,
to
some
extent
you
can
imagine
that
even
with
EPP,
for
example,
I
mean
we
know
what
the
registration
data
looks
like.
There
are
some
fairly
definitions
of
a
lot
of
this
data.
That's
there,
okay,
there's
derived
data,
that's
in
some
of
these
reports,
but
there's
a
certain
stable
set
of
data
which
is
there.
We
know
what
that
is.
A
So
that's
the
reporting
elements
you
know
being
being
standardized.
You
want
to
know,
what's
in
a
report
and
and
be
able
to
consume
them
easily
and
not
have
to
look
at
each
one
as
as
an
individualized
registry
based
thing,
okay,
and
then
we
also
want
to
have
an
unknown
set
of
reports.
We
want
to
have
a
way
to
consume
what
reports
are
likely
to
look
like
okay,
so
that's
sort
of
you
know
where
we,
where
we
are
today
and
kind
of
the
model
of
where
we'd
like
to
get
to
in
all
this
next
slide.
A
So
there
basically
are
two
principal
parts
of
this
proposal
at
the
moment.
The
concept
here
in
both
of
these
parts.
So
this
is
part
one
I
had
some
pretty
good
traction
in
the
tech
ops
group
last
time,
but
from
the
point
of
view
of
the
idea,
what
we
do
is
we
create
and
INR
registering
if
you
think
of
these
reports
as
being
a
CSV
file
right,
that's
what
each
report
would
look
like.
A
So
if
you
imagine
that
as
the
concept
here,
we
create
an
E
and
I
in
a
registry
and
we
model
this
after
the
way
the
epp
extensions
was
done,
which
is
you
know
what
sort
of
formed
this
group
and
cause
this
group
to
come
into
existence
when
we
first
did
that
document,
and
so
the
column
heading
registry
would
have
the
following
information.
That's
listed
there
each
particular
column
heading
we
get
an
ordinal
value
and
you'll
see
why
that's
relevant
when
we
get
to
the
example.
A
Obviously,
the
name
of
the
column,
a
reference
to
the
definition
of
the
data,
that's
there,
which
of
course
would
also
define
syntax
for
the
element.
Okay
and
then
you
want
to
know
where
the
element
came
from
and
some
other
administrative
elements,
but
you
know
that's
just
sort
of
the
registry,
that's
in
Ayana
and
it
would
be
a
first-come-first-served
registry,
much
like
the
epp,
extensions
register
areas.
So
there's
no.
The
only
strictness
here
about
it
is
that
the
whatever
you
put
in
the
registry
is
self-consistent
and
doesn't
conflict
with
anything
else.
A
R
Hi
James
Jimmy,
it's
just
a
statement,
the
bleedin
obvious
here,
but
whenever
these
things
could
be
put
in
a
first-come,
first-served
basis,
I
hope
this
could
be
information
recorded
about
who
was
that
asked
for
this
particular
column
to
be
added
to
the
registry,
I've
imagined
the
good
of
a
situation
where
our
registry
asks
for
some
kind
of
a
karmic
station.
Boo
boo
here
doesn't
get
used,
it's
forgotten
about,
and
then
cover
comes
always
a
5-10
years.
Time
then
sees
is
anybody
using
this
thing,
who's
responsible
for
that
can't
get
rid
of
it?
Yes,.
A
That's
just
sort
of
a
standard
problem,
first-come,
first-serve
registries
and
do
I
understand
that
you
know
the
only
requirement
would
be
that
the
reference
of
the
definition
exists.
Maybe
we
do
need
to
have
a
process
for
cleaning
up
the
registry
if
it
gets
big,
but
we're
not
going
to
address
that
right
now.
We
don't
have
that.
We
don't.
We
don't
speak
to
that
issue.
Even
with
EPP
extensions.
I
was.
A
No
registrant
to
the
element,
its
captured
right
there,
okay,
one
of
those
things-
yes
yeah,
we
do
know
who
put
it
there,
which
doesn't
mean
that
you're
gonna
be
able
to
reach
them
again,
because
you
know
how
that
goes.
He
mail
addresses
change.
I
mean
you
know
that
doesn't
really
make
the
problem
go
away,
but
okay,
next
slide
now,
there's
actually
four
of
these
slides
and
I'm
not
really
gonna
walk
down
through
them.
A
A
So
the
RFC
number
there
is
just
the
same
for
all
of
them,
whatever
we
put
in
our
first
document,
if
we
get
that
far
and
as
is
typical
in
these
mechanisms,
in
this
case,
it
would
be
the
is
G
would
be
the
registrant
only
because
they
would
be
find
in
an
RFC.
The
specification
would
be
there
and
would
be
a
working
group
product.
A
So
that's
one
of
the
registry
surtout
two
parts
to
this
proposal.
One
is
to
have
a
int
registry
of
the
column
headings,
so
the
data.
Essentially
that
goes
into
the
reports
next
slide.
The
next
thing
is
to
similarly
create
and
I
in
a
registry
of
actual
reports
that
are
used
and
what
they
look
like,
and
you
know
this
is
all
exactly
what
you
would
expect
it's
fairly
obvious
stuff.
A
You
know
the
report
name
reference
to
the
definition,
and
this
is
the
critical
part
that
ties
it
back
to
the
other
registry,
the
ordered
list
of
column
headings
in
the
report
using
the
ordinal
value.
So
let's
go
to
the
next
slide
and
I'll
show
you
what
that
looks
like
this
is
actually
the
list
of
nine
reports
that
are
on
the
best
practice
that
domain
site.
K
A
And
in
fact,
we
had
quite
a
lot
of
discussion
about
this,
even
in
the
tech
ops
group
going
back
to
the
may
global
domains,
missions,
ICANN's
GDD
summit,
when
the
tech
ops
group
had
a
meeting
there.
There
was
a
lot
of
discussion
about
why
this
needs
to
be
in
in
in
the
IETF
is
sort
of
the
selected
SDO,
if
you
will,
to
put
it
in
the
problem
with
best
path,
suits
best
practice,
thought
domains
as
compared
to
this
is
it's
not
a
persistent
archived
reference?
That's
the
issue.
A
K
Create
the
key
top
repository
is
probably
more
stable
than
best
practiced
on
domains.
You
know
we
had
the
discussion
before
this
is
rubber,
stamping
of
a
draft
so
that
it
gets
an
RFC
number
so
that
somebody
can
work
after
registry
or
registry
and
say
hey
it's
an
RFC.
You
need
to
implement
it.
That's
the
only
reason-
and
that
was
Tobias
said
to
me
in
person
well.
K
A
I
don't
view
it
as
rubber
stamping
I
I
can
see
where
one
might
think
of
it.
That
way,
the
the
ICANN
is
not
a
technical
body.
In
that
way,
I
would
not
expect
I
can
as
a
body
to
produce.
You
know
this
kind
of
technical
specification
just
meet
personally
and
in
general,
there's
a
there's,
a
relationship.
Broadly
speaking,
between
the
IETF
and
and
and
I
can
you
know,
technical
specifications
are
generally
looked
for
from
from
the
IETF,
for
the
most
part
and
I
can
does
the
policy
work.
A
That
goes
that
sits
on
top
of
these
specifications.
I
mean
that's
just
me
personally
sort
of
talking.
Others
may
have
a
suddenly
more
nuanced
view
about
it.
All
you're
right,
I
I,
have
said
about
the
best
practice
that
domains
thing
that
you
know
as
a
as
a
registry.
Okay,
you
know
on
the
business
side,
I
don't
want
to
implement
something
I
don't
want
to
move
toward
something
which
is
not
in
fact
a
a
persistent
and
archived
reference,
and
you
know
I
can,
as
an
organization
just
doesn't
have
that
facility.
A
K
A
A
A
There
was
no
particular
consensus
about
them,
so
I
I
collapsed,
based
on
the
on
the
comments
that
were
in
the
tech
ops
meeting
these
three
items
into
you
know
just
baseline
requirements
is
what
I
called
them
here,
but
anyway,
the
reports
would
be
CSV
files,
their
reaction
from
folks
in
and
I
thought.
This
was
kind
of
interesting.
I.
A
Hadn't
really
thought
about
this
until
somebody
started
talking
about
it,
but
if
you
start
talking
about
actually
creating
a
file
or
a
file
name
or
it
being
a
CSV
file,
as
opposed
to
focusing
on
the
framework
in
which
to
produce
the
reports.
Whatever
the
report
is
whether
the
report
is
a
file
or
some
other
delivery
mechanism
right,
then
you
need
to
separate
that
the
distribution
mechanism,
the
publication
mechanism,
out
from
all
of
that
that
was
early
discussion
we
had
gotten
into
some
people-
may
not
want
to
produce
these
reports
as
files.
A
They
may
have
other
mechanism
for
doing
it
and
all
the
reasons
for
doing
that,
which
might
be
perfectly
reasonable.
So
an
open
question
really
at
large
in
the
community
is
what
do
we
want
the
distribution
mechanism
to
look
like
and
do
we
want
any
kind
of
stability
in
that
or
not
so
that
remains
to
be
an
open
question
and
then
just
you
know
the
general
question
of
unrecognized
column
headings.
A
A
Some
of
that
depends
a
little
bit
on
the
distribution
mechanism,
but
we
can
probably
find
some
words
that
move
towards
the
direction
of
just
you
know,
ignoring
them
or
at
least
being
able
to
consume
them,
but
not
actually
doing
anything
with
them
sort
of
have
to
talk
about
what
we
want
that
to
look
like.
So
that's
an
open
question
next
slide.
A
We
did
have
some
discussion
at
the
time
because,
when
I
had
presented
it
at
that
time,
discussion
about
a
file
name
because
there
are
other
kinds
of
metadata
issues.
So
one
of
the
things
that
comes
up
is
we
do
have
the
data
set
file
format
which
this
group
has
looked
at
before.
We've
had
a
presentation
about
it
and
talked
about
it.
One
of
the
interesting
things,
a
clear
distinction
between
the
data
set
file
format
and
this
proposal
is
the
data
set
file.
A
Format
actually
does
cover
the
metadata
and
the
full
set
of
metadata
that
would
go
with
this
reporting
mechanism.
This
kind
of
has
implied
metadata
or
some
amount
of
metadata.
It
would
be
in
the
file
name
if
we
were
to
specify
a
file
name
for
it,
but
that
of
course
implies
a
certain
distribution
mechanism.
So
there's
some
question
as
to
whether
that's
the
right
thing
to
do,
and
maybe
we
need
to
do
something
different,
and
so
you
know
that's
why
all
of
this
is
there.
This
was
what
the
original
proposal
wasn't
thinking
about.
A
Filenames
we
tried
to
put
out
there
sort
of
the
minimum
kind
of
metadata
that
one
might
want
and
need
as
part
of
doing
this
report.
But
again
it
just
became
an
open
question
when
it
was
all
done,
I
think
that's
it.
Isn't
it
yeah.
That
was
the
last
slide.
So
that's
where
we
are
so
these
last
two
slides
are,
you
know,
still
just
sort
of
discussion
points
I
expect
that
we,
the
the
next
steps
here,
are
that
we
will
have
some
discussion
continuing
on
our
on
our
mailing
list.
A
S
Zdenek
I'm,
not
so
much
about
or
against
standardizing.
This
Alex
is
I'm
a
bit
okay,
I'm
unimpressed
about
this
I
just
have
the
feeling
that
we're
you
know
this
working
group
is
over
and
over
and
over
again
standardizing
the
same
things,
and
this
is
just
a
new
variation
of
escrow.
If,
if
this
group
says
that
escrow
is
a
working
group
item
and
we
define
escrow
formats,
this
is
the
same
thing
just
that
the
flow
of
the
data
is
in
another
direction,
but
coming
up
with
a
new
syntax
and
column
headings,
and
it's
it's.
A
I
just
trying
to
think
about
how
to
to
your
right.
You
know
all
of
these
are
about
data
flow.
I
guess.
The
only
immediate
observation
occurs
to
me
is
the
actual
data
in
each
of
these
two
sets
of
things
really
is
somewhat
different.
You
know
the
escrow
is
about
the
registration
data.
These
reports
are
more
about
data.
That's
coming
through
a
pp
and
collecting
elements
that
are
coming
from
there,
especially
the
transaction
reports,
for
example-
or
you
know,
name
service
that
go
with
the
domain
name.
A
So
there's
a
it's
not
always
true,
I
mean
there's
a
bias
away
from
personal
information,
except
that
there
are
reports
that
do
have
personal
information
in
them.
So
that's
not
really
a
hundred
percent.
True
the
data
escrow
is
very
clearly
all
the
registration
data.
There's
there's
a
lot
more
data
in
these
reports.
That
is
not
in
escrow
I.
Guess
is
really
kind
of
my
point
at
the
moment,
but
although
I
said
I
take
your
point,
I
just
I,
don't
know
what
to
do
with
it.
Yet
go
ahead.
Alex
Alex
again.
K
To
be,
quite
frankly,
quite
clear:
I'm
not
against
analyzing
those
things,
because
we
all
know
that
those
are
a
lot
of
a
burden
to
the
community
of
the
registries.
Registrar's
yeah
I,
just
as
I
said
a
couple
times,
I,
don't
feel
that
an
RFC
is
like
the
right.
The
right
when
you
to
publish
it
and
to
be
to
give
like
the
this
a
little
bit
of
more
of
a
productive
touch.
K
For
example,
there
is
something
that's
called
the
registrar
registry
data
group
that
exists
is
like
an
informal
group
within
the
center
environment
sort
of
like,
and
we
have
been
doing
some
kind
of
standardization
here
as
well,
and
we
have
published
a
couple
of
documents:
web
pages
on
on
a
web
page
that
that
states
how
V
is
group
belief
that
things
should
be
done
and
people
are
actually
implementing
that.
So
so
that
could
be
another
way.
K
It's
a
little
bit
sad
to
see
that
to
understand
that
there's
C,
PhD
cups
can't
publish
stable
documents
if
I
get
that
right.
Those
stable
document
references
but
yeah
so
again,
I
have
nothing
against
standardizing.
Those
things
feel
that
the
scope
of
the
IDF
doesn't
really
fit
the
purpose
of
those
documents,
100%.
D
Can
step
in
chair
head
off,
I
hear
an
interesting
thing
here:
we've
had
this
discussion
before
you
know,
I
realize
that
tech
ops
in
Wadena
I
can
is
a
gTLD.
Only
accessible
group
centre
is
a
ccTLD
exclusive
group,
we're
here
in
the
IDF
to
standardize
things.
If
we
want
to
standardize
things,
we
should
open
these
groups
and
discuss
among
them
among
each
other.
Now
what
the.
E
A
A
It
is
at
least
another
reason
why
bring
me
to
the
ITF
is
sort
of
an
ideal
thing,
because
it
is
an
open
group
and
I
know
that
it's
easy
to
think
that
something
originates
in
ICANN
and
and
people
have
a
certain
target
view
about
ICANN
wanting
to
point
a
negative
finger
at
them
for
any
number
of
reasons.
But
you
know
speaking
for
myself
I,
you
know
this
idea
for
this
work
might
have
originated,
that
I
can
but
I
don't
see
that
as
any
different
than
the
work
originating
anywhere
else.
A
You
know
I
mean
the
idea
came
up,
it's
a
problem
that
needs
to
be
solved.
You
know
from
my
point
of
view,
speaking
personally,
this
is
a
good
home
for
solving
it.
I'm
gonna
take
advantage
of
whatever
I
need
to
take
advantage
of
to
get
the
best
work
possible
and
I
think
that
it's
incumbent
on
us
to
look
at
both
the
what
Center
has
done
and
what
you
know.
A
The
the
tech
ops
group
is
sort
of
proposing
and
we
bring
them
here
in
this
community
and
we
discuss
them
here
openly
and
bring
both
sets
of
groups
here.
So
I,
don't
I,
don't
see
this
as
a
as
a
stumbling
block
or
a
concern.
I
see
it
as
an
opportunity.
You
know,
and
let's
just
bring
the
work
here
and
do
the
right
thing
with
it,
and
that's
really
what
I'm
after
here
just.
D
A
You
know
I
I,
don't
know,
I,
think
that's
a
standard.
Probably
if
you
will
a
standard
problem
in
any
ITF,
you
know
making
sure
you've
got
the
right
community
of
people,
but
you
know
we
have.
We
have
put
together
a
community
of
people
who
have
a
shared
problem
and
they
want
to
have
a
a
stable.
You
know
singular
if
you
will
solution
to
that
problem
and
we're
just
a
group
of
people
moving
towards
that,
and
you
know
that's
sort
of
the
role
that
the
IETF
plays.
Do
we
have
everybody
in
the
IHF
that
we
need?
A
R
R
B
Q
Thanks
Rick
Wilhelm,
just
a
comment:
Jim
I
think
your
your
comments
about
the
CPI
tech,
ops
are
largely
right
on
I
will
offer
that
there's!
There's
not.
While
there's
been
a
fair
bit
of
discussion
about
this
at
CPA
checkups,
there's
not
a
complete
agreement
and
consensus
on
the
problem
to
be
solved.
A
You
so
thanks
for
all
the
comments,
I
again,
I
think
what
we're
gonna
do
here
is
is
continue
this
just
as,
as
you
know,
design
work
evolutionary
work
much
like
registry
mapping,
it's
just
gonna
move
forward
with
a
group
of
people
and
and
we'll
see
where
we
get
to
with
that.
So
we're
not
doing
any
kind
of
call
for
adoption
yet,
but
this
is
just
a
heads
up
that
this
kind
of
thing
is
moving
forward
and
it'll
stay
visible,
just
like
registry
mapping
in
this
group
and
and
we'll
see
where
it
goes.
D
It
never
do.
Thank
you
Jim.
You
know.
Well,
actually,
as
part
of
this,
this
item
on
the
agenda,
we
were
going
to
try
to
have
discussion
on
the
new
milestones,
but
looking
at
the
time,
I
think
we
will
move
that
over
to
the
to
the
mailing
list,
because
we
still
have
two
presentations
and
we
only
have
ten
minutes
left.
D
O
O
After
last
meeting
discussion
about
the
possible
replacement
of
jacquard
weave
Jay's
contact
in
our
top
40
could
be
useful
for
the
working
group
to
have
a
short
overview
of
Jay's
contact.
To
make
you
more
aware
of
its
fine
features,
but
at
the
same
time
to
demonstrate
that
it
could
really
be
a
more
efficient
alternative
to
jihad
and
in
brief
Jay's
quantity
is
a
new
contact
cut
the
representation
alternative
to
be
hard
like
Jacobs
json-based,
and
a
fully
support
the
book
are
content,
but
it's
not
directly
derived
by
be
cut
it.
O
It
follows
an
uglier
structured
approached
the
information
modeling,
the
main
object
define
the
contact
card
named
jes
card.
Any
collection
of
cotton
cards
named
Jess
car
group.
The
draft
is
the
devastation
of
the
draft,
is
0-5
and
is
written
by
me
and
together
with
Robert
Stephanie
of
first
male
and
the
current
working
group
is
dispatch.
Even
if
gem
map
seems
to
be
it.
O
Thank
you.
The
the
the
draft
obviously
is
still
in
brown
in
progress.
We
are
some
open
issues
on
the
table,
in
particular
how
to
represent
the
gender
information.
If
we
should
include
endow
to
include
the
information
needed
for
teasing
or
multiple
versions
of
the
same
contact
card
and
which
is
the
best
way
to
represent
the
information
about
the
preference,
a
new
version
is
ready
to
be
published.
O
One
minute
jump
to
skip
this
I
want
to
only
to
provide
you
with
some
examples.
In
the
left
side
of
the
slide.
There
is
an
extract
from
inaudible
response
using
a
jacquard
and
the
red
side.
There
is
the
corresponding
version
of
the
Jas
card.
The
properties
involved
are
currently
required
in
adapt.
The
other
two
examples
are
taken
by
some
use.
Cases
provide
me
prior
to
me
by
Tamera
zone
to
test
the
J's
contact
capability
to
represent
multilingual
information
and
a
structure
data
like
formatted
the
addresses
and
formatting
names.
O
O
The
first
scenario
corresponds
to
the
reverse
state
who's,
implementing
the
current
adapt
standard,
so
it
is
identified,
but
they
are
double
level
zero.
Taking
that
of
conformance
array
in
this
scenario,
J
cadiz
require
and
J's
card
is
optional.
It
can
be
requested
by
setting
the
parameter
parameter
just
cut
to
true,
and
the
next
scenario
is
the
scenario
corresponding
to
when
the
transition
is
completed.
As
in
this
scenario,
they
serve
implements
J
J's
code,
as
required
and
jagged
as
optional
I
think
that
this
transition
model
has
some
advantages.
O
Only
one
content
representation
would
be
including
to
the
response.
The
response
would
always
be
compared
to
have
c74
t3,
but
what
is
much
more
important
is
that
backward
compatibility
will
be
guaranteed
throughout
the
transition
and
the
Severson
kind
could
execute
the
transition
in
an
independent
way.
O
K
So,
very
quickly
we
did
a.
We
did
a
site
meeting
next
slide.
Please,
on
the
main
suggestion
on
Tuesday
morning,
great
about
15
people
in
the
room.
Some
of
them
were
reading
email,
I
guess
it
was
mostly
registry
site
people
and
yeah
next
slide.
Please
so
the
main
suggestion
we
I
guess
we
all
know
what
it
is.
The
customer
wants,
a
domain
name
domain
name
is
taken
and.
K
K
So
the
question
is
now
is
registrar's
that
was
like
directly
to
registry
end
of
things.
Registrar's
also
want
to
do
that.
Maybe
some
of
them
have
quite
sophisticated
tools
already,
but
if
they
actually
fetch
information
from
the
registries
for
that-
and
they
might
want
to
have
a
standardized
API
in
order
to
get
that
from
the
registries
yeah,
so
registrar's
deal
with
many
registries,
so
in
in
turn,
it
would
be
really
said
if
each
and
registry
invented
their
own
API
for
dealing
with
suggestions.
Next,
please
yeah,
essentially
the
protocol
arena.
K
We
could
do
that
they
were
over
APB.
We
could
do
that
order
up.
We
could
do
it
over
some
other
arrests.
Other
protocols
there's
a
range
of
input
data.
That's
maybe
useful
to
create
domain
name
suggestions
for
a
customer,
some
of
that's
actually
a
personal
information
of
the
customer.
So
that's
tricky
that
the
area
can
work
in
next
one,
so
there's
existing
work,
there
series
things,
there's
an
EPP
extension
from
Verisign
that
actually
got
as
far
as
understand,
deprecated
or
is
pulled
out
out
of
the
SDK
in
favor
of
a
rest-based
model.
K
There
is
some
work
on
our
debt-based
by
Mario.
He
uses
a
link
in
a
standard
up
response
to
point
to
a
suggestion:
server
and,
and
then
he
was
like
a
lightweight
domains,
archery
surgery
and
then,
as
there
is
not
a
PP
extension
that
that
I
actually
created
because
I
wasn't
aware
of
the.
Where
is
an
extension
that
extends
the
domain
check
response
next.
K
So
what
was
the
major
discussion
during
the
site
meeting?
So
the
major
points
where
the
the
register
is
better
positioned
and
it
has
a
better
vantage
point
and
the
registry
probably
for
many
things,
because
he
skills
to
the
customer.
So
he
knows
what
the
customer,
once
suggestion
should
sort
of
like
belong
to
the
free
market.
It's
not
something
that
the
the
the
registration
to
and
the
registry
has
like
a
little
bit
better
Wantage
point,
because
they
are
aware
of
expiring
domain
names
and
stuff,
like
that.
K
The
problem
with
that
was
that
the
room
was
full
of
registries
in
the
way
a
few
registrar's.
So
next
one
place
your
discussion.
If
we
would
have
time
that
would
have
been
the
points
that
I
would
want
to
discuss.
But
to
sum
it
up
in
one
sentence:
I
think
I
will
go
ahead
and
do
some
rest
based
API.
That
I
will
send
out
to
whatever
other
group,
probably
and
and
see
if
somebody
else
is
interested.
Yeah
from
my
point
is
interesting,
is
reg
X
the
right
when
you
I
start
believing
it's
not
yeah
Roger.
E
R
You
read
I'm,
sorry
to
see
Alex
I
think
this
is
a
very,
very
bad
idea.
It
said,
doesn't
need
to
be
standardized
I'm,
giving
you
their
comments,
but
rubber-stamping
I
think
it's
rather
nitronic
suggesting
bringing
up
other
BOTS
to
the
regex
which
might
be
getting
done
elsewhere.
I!
Think,
mr.
pilot,
you
just
kill
it,
don't
bring
here.
Ok,
fair
enough.
D
H
H
We
now
have
production
implementation
experience
anyway,
long
and
short
of
it
I'm
thinking
it's
time
that
we
look
to
address
the
captured
errata,
which
are
all
editorial
as
far
as
I
can
tell
and
take
on
an
effort
to
move
those
five
documents
to
internet
standards
status.
So
I
had
mentioned
this
at
the
Montreal
meeting.
You
know
had
a
couple
of
sidebar
conversations
attempted
to
get
some
things
started
on
the
list
without
a
whole
lot
of
success,
but
I
do
have
a
74
82
bits
sitting
on
a
machine.
H
You
know
right
over
there
and
what
I'm
going
to
propose
is
that
we
take
on
this
effort
and
if
that,
if
we
agree
that
we
want
to
do
that,
I
will
volunteer
to
do
a
little
bit
of
cat
herding
in
terms
of
coming
up
with
proposals
for
document
authors
and
document,
shepherds
and
and
whatnot.
So
I'd
like
to
ask
the
chairs
in
our
ad.
If
you
think
that
this
is
work
that
we
can
take
on.
A
So
thank
you
for
that
Scott
and,
as
folks
might
expect,
the
80s
and
the
chairs
have
all
had
this
discussion
and
we
generally
agree
that
this
is
good
work
to
address
with
and
that
we
should
do
this.
So
it's
just
a
matter
of
finding
the
right
means
to
do
it.
There
is
a
question
about
our
Charter
and
we'll
review
that
we
might
need
a
tweak
to
the
Charter.
A
We
might
not
that's
an
open
question,
but
we
think
this
is
a
good
good
spot,
and
this
speaks
to
George
mikaelsons
issue,
which
he
has
now
left
the
room,
and
so
he's
not
going
to
hear
this
this,
along
with
you,
know,
sort
of
the
j-card
stuff,
all
kind
of
fall
on
to
the
are
DAP
side
of
our
work
items.
So
there's
plenty
of
momentum
here
going
on
on
both
sides.
So
with
that.