►
From YouTube: IETF105-REGEXT-20190725-1000
Description
REGEXT meeting session at IETF105
2019/07/25 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
Right,
it
is
just
ten
o'clock,
so
let
us
get
ready
here.
This
is
the
registration
protocols,
extensions
working
group
and
I
am
James
Calvin.
Most
people
here
on
tour
know
me
you
Anton
for
Schwerin
is
with
us
in
miyako
and
yes
so
he's
waving.
Look
at
that
and
yeah
this
picture
up
there
too.
That's
awesome,
you
want
to
say
hello,
and
we
heard
you
it's
great.
Oh
no,
didn't
hear
that
not
hearing
you
up
there,
you
go.
B
A
Okay,
it's
skipping
right
ahead.
This
is
the
usual
note.
Well,
I'm
sure
you've
seen
it
many
times.
It's
already
Thursday
this
week
and
many
of
you've
been
here
all
week,
so
I'm
sure
you've
seen
this
many
times
and
just
important
to
keep
that
in
mind,
and
so
we'll
jump
right
in
here
to
our
agenda.
We
do
have.
A
A
I
realize
that
not
every
document
is
important
to
everyone,
so
you're
not
going
to
give
it
a
detailed
review
and
study,
but
please
do
take
the
time,
especially
during
last
call
to
read,
read
the
documents
and
take
a
look
at
them
and
acknowledge
that
you've
read
them
and
don't
have
any
issues
with
them.
It's
very
important
to
be
able
to
show
some
consensus
here
on
our
documents
and
we
really
appreciate
that.
Okay,
let's
go
to
some
of
our
existing
documents.
Yeah
for
us,
we've
had
three
RFC
since
our
last
meeting.
A
This
is
this
is
absolutely
wonderful.
So
we
have
had
a
very
productive
year
this
year,
moving
some
things
along
that
kind
of
a
slow
start
there
for
a
while,
but
we've
got
our
change
polis
al.
We
got
the
organizational
mapping
and
extension
documents
published.
So
that's
a
good
thing
and
we
have
two
documents
that
are
currently
in
is
G
evaluation.
We
have
some
comments
that
we
just
have
to
resolve
that.
A
Don't
think,
there's
anything
particularly
material
going
on
in
these
things,
but
I
know
that
both
sets
of
document
Shepherds
know
that
they
have
work
to
do
and
they've
acknowledged
to
us
that
they're
going
to
move
those
documents
forward
and
we're
gonna.
We
need
a
new
version
of
the
feed
document.
I,
don't
think
the
bundling
needs
a
new.
Oh,
it
does
need
a
new
document.
You
know
the
bun.
They
need
a
new
document
too,
so
it'll
be
one
more
of
those
that
will
then
get
pushed
out
into
the
publication
cycle,
so
those
are
moving
along.
D
A
There's
seven
changes,
yes,
Roger
saying
that
there's
seven
comments
to
be
addressed
in
seven
things
that
he
has
to
take
care
of,
but
all
all
doable.
Okay,
quick
milestone
of
you.
We
had
kind
of
proposed
these
milestones
didn't
really
get
a
whole
lot
of
discussion
about
them.
But
you
know
here
they
are
just
putting
them
up
here
again.
Login
security
at
the
top
is
actually
in
working
group
last
call
which
will
close
the
week
after
the
IETF
it'll
close
next
Friday,
not
tomorrow,
the
data
escrow
and
the
DNR
D
objects.
A
A
We
don't
have
an
agenda
item
today
for
the
open,
ID
stuff,
there's
nothing
to
progress
at
the
moment
there,
but
it's
also
a
further
out
target
for
us,
so
we're
just
waiting
for
some
activity
there.
Okay!
So
now,
let's
move
into
our
existing
work
and
we'll
jump
right
into
a
few
presentations
here.
I
put
login
security
up
here,
not
because
anybody
was
going
to
talk
about
it,
but
just
as
an
opportunity
to
remind
us
that
it
isn't
working
group
last
call
that
will
close
next
week.
We
normally
do
a
two-week
working
group.
A
Last
call
made
this
one
three
weeks
because
we
only
opened
it
last
week
and
we
didn't
you
know
to
allow
an
extra
week,
because
this
is
the
ITF
week.
So
we're
kind
of
just
ignoring
the
fact
that
that
week
is
there
but
again
not
expecting
a
whole
lot
of
discussion
not
expecting
any
issues.
But
please,
as
a
reminder,
please
do
read
the
document.
Please
indicate
that
you've
read
it
and
that
you
have
no
objection,
even
if
you
don't
explicitly
support
it
or
have
a
need
for
it.
A
It
is
useful
to
to
know
that
people
are
looking
at
the
documents
and
moving
them
along.
That's
really
very
important
really
could
use
some
help
and
getting
more
people
to
acknowledge
that
they're
paying
attention
to
the
work,
so
the
data
s
crew
drafts
will
actually
be
up.
First
and
Gustavo's
can
do
this,
but
Frederick
Frederick,
you're,
gonna
Francisco,
not
Frederick.
So
let
me
get
your
slides
up.
A
E
What
is
the
Rascoe
is
a
process
by
which
some
parts-
usually
the
registries
registers
in
the
minimum
space-
store
critical
data
necessary
to
restore
service
in
case
of
catastrophic
failure,
and
they
usually
do
this
with
a
tea
party,
normally
called
that
is
corrosion,
and
there
is
usually
some
contractile
conditions
that
if
they
are
met,
for
example,
an
emergency
failure,
then
the
data
could
be
released
who
to
party
beneficiary,
for
example,
in
the
case
of
Italy's
I,
can
so
that
I
can
give
it
to
someone
else
to
run
the
race.
Your
the
register
next
slide.
E
An
order
for
the
specification
had
been
stable
now
for
a
couple
years
or
more
and
only
minimal
updates
have
been
done,
basically,
maintenance
or
minimal
issues
that
have
been
detected
and
next
slide,
and
the
drafts
I
think
this
is
just
a
quick
history.
They,
it
was
originally
one
draft
he
was
fit
into
two.
Then
there
was
the
proposal
by
Jing
qu
here
and
others
to
extend
the
format
to
not
only
be
XML,
because
the
original
proposal
was
only
XML,
as
so
the
proposal
so
Jim
and
others
proposed
to
make
it
be
basically
a
dual
format.
E
E
What
is
called
the
where
mark
that
is
the
day
and
time
corresponding
to
when
the
deposit
or
when
the
data
from
the
registry
or
the
database
has
been
pull
so,
for
example,
if
the
data
escrow
deposit
is
corresponding
to
today,
we
the
time
some
of
today
the
format
is
also
extensible,
so
you
can
define
you
can
identify
the
extensions
that
are
being
used.
The
objects
are
being
a
screw
there
next
slide.
The
objects
mapping
is
is
what
you
defined
the
work.
E
What
are
the
definition
for
all
the
objects
that
can
be
escrow
is
is
define,
as
I
said,
before
it's
supposed
to
format,
xml
or
CSB
next
slide.
This
is
the
list
of
objects
are
defining
the
in
the
document.
This
list
has
not
changed
for
four
years
now.
You
will
find
what
the
typical
type
of
objects
you
find
in
a
registry.
E
The
Menem
ratio
register
next
slide,
who
uses
the
other
Astra
format.
As
I
said,
most
of
the
deities
are
using
this
excuse
me,
since
the
launch
of
the
new
Tilda
round
in
2013.
This
has
been
in
use,
and
nowadays
even
some
legacy
utilities
have
moved
to
this
new
format.
Excuse
me,
so
it's
been
used
for
the
data.
Escrow
obligations
are
contained
in
the
contract,
but
also
is,
we
understand,
has
been
used
by
races
when
they
are
transitioning,
so
it,
for
example,
register
is
changing
from
race,
the
service
provider,
and
they
typically
use
this.
E
The
rest
grow
format
to
transmit
data
from
one
hour
speed
to
another.
It
is
also
being
used
by
the
corresponding
their
escrow
agents.
I
believe
we
have
nine
in
a
little
space
and
all
of
them
currently
supported
format.
They
have
to
do
some
validations
per
contract.
They
have
with
icon
and
I,
have
to
confess
within
check.
If
this
is
being
used
in
other
contexts,
for
example,
Z
tilde
space,
it
is
also
being
used
as
in
the
Italy
space
by
the
emergency
button
range
operators.
This
is
a
service
we
have
United
contract,
we
have.
E
Three
providers
are
really
available
to
take
over
TL
leave.
There
were
some
emergency
and
we
totally
had
to
use
this
year
or
two
ago
with
one
detail.
It
had
a
failure,
one
of
the
critical
functions
that
are
described
in
the
contract,
so
that
that
really
was
successfully
taken.
But
why
buy
one
of
the
Ebro
providers
and
we
used
the
Rosco
format
to
rebuild
the
LD
it
is.
It
has
another
use,
also
in
the
icon
contract.
E
So
we
we
think
these
straps
are
quite
mature.
They
have
been
around
for
several
years,
and
so
we
know
this
has
been
just
adopted
by
the
working
group
recently,
however,
likes
that
we
we
think
they
are
ready,
they
have
been
used,
they
are
being
used
by
several
parties,
so
we
are
asking
whether,
if
you
guys
agree
that
it
would
be
wise
to
now
go
directly
to
working
low,
classical
and-
and
there
are
the
two
drops-
that's
it.
Thank
you.
A
F
F
B
A
E
G
She
go
from
Verisign
yeah
we've
actually
gone
through
that
site
or
the
length
of
these
drafts.
It
livings
in
existence,
but,
in
essence,
is
in
front
a
standard
file
format.
That's
used
for
s
pros,
it's
not
a
operational
practice.
It's
actually
a
file
format
and
it's
used
by
many
many
different
parties
in
the
registry
industry,
so
I'm
not
sure,
would
be
a
good
fit
for
informational.
I,
really
see
it
as
a
standards
track
based
on
its
usage
and
the
fact
that
it's
defining
standard
file,
format.
A
And
I
guess
for
me
what
I
would
add
to
that
is
just
that.
It
is
a
in
essence.
It's
a
communication
mechanism.
It's
a
protocol
for
communication
between
parties,
so
file
format
is
what
it
is,
because
you're
transferring
a
whole
file,
but
it
is
really
a
communication
method
and
the
syntax
and
semantics
for
all
of
that
so
I
think
standards
track
is,
is
the
right
thing
for
it
did
you,
so
let
me
just
go
back
to
Antoine.
Did
you
have
a
preference
that
it
not
be
standard
to
track?
Well,.
G
The
very
same
again,
actually
I
was
thinking
that
it
might
be
a
good
idea
for
us
to
add
an
implementation
status
section,
considering
the
fact
that
we
have
so
many
mutation
with
us
that
we
go
ahead
and
update
the
drafts
to
see
that
yeah.
I
H
I
Is
you
know
from
the
data
that
gets
collected
in
certain
cases
is
going
to
have
contact
data,
and
so
obviously
it
needs
to
technically
get
escrow
for
the
written
order
for
the
escrow
to
fulfill
its
function,
but
it
is
gonna
be
having
that
data
in
there.
So
it's
just
something
that
is
like
worth
considering
and
then
and
in
the
last
second
late
and
lastly,
who's
that
it's
it's
good,
that
we're
standardizing
format
again.
Sir.
Certainly
support
about
that.
I
But
the
given,
what's
going
on
in
the
land
of
gTLDs,
the
expedited
policy
development
process
related
at
registration
data,
the
the
data
that
is
collected
by
registrar's
and
registries
is
likely
to
be
morphing
and
changing
over
the
next
period
of
time
relatively
soon.
And
so
it's
unclear
to
me
at
present.
What
sort
of
flexibility
is
already
built
into
the
standard
to
accommodate
this?
Or
are
we
going
to
need
to
rev
this
document
in
order
to
accommodate
some
possible
future
changes
to
the
escrow
format
that
might
be
driven
by
the
changing
registration
data
requirements
right
so.
E
The
data
scroll
specification
was
defined
with
have
any
minds
for
multiple
set
of
contract,
our
policy
requirements,
so
the
the
way
was
the
finest
makes
almost
everything
optional
and
it's
up
to
some
other
means
contract
policy,
whatever
to
make
the
list
of
things
that
need
to
be
included,
and
so
in
that
sense,
I
think
we're
safe.
But
it
would
be
great
to
hear
what
you
think
or
others
thing
about
that:
okay,.
K
I
L
A
A
It
is
interesting
the
question
that
about
the
future
of
this
document
in
format,
given
what
is
going
on
and
I
can
or
what
it's
gonna
do.
I,
don't
know
how
to
respond
to
that
right
now,
but
we
should
take
the
discussion
to
the
mailing
list.
Part
of
what's
going
on
here,
in
my
mind,
is
some.
These
things
have
been
broadly
used,
broadly
deployed,
for
you
know
almost
a
decade
now,
I
think
the
documents
are
pretty
well
baked
and
it
is
important
and
useful
to
to
get
that
document.
Publication
closed
that
cycle.
A
Let's
have
a
discussion
on
the
list
as
to
how
far
we
want
to
want
to
take
revisions
to
this
document.
It
may
be
that
it's
we
should
iterate
on
the
document
and
iterate
on
a
published
document
instead
of
iterating
on
this
specification
at
this
point
in
time
is
a
better
thing
just
because
of
the
broad
deployment,
while
we
wait
for
other
things
to
happen,
so
that
would
be
my
personal
comment,
all
of
it
I'm
generally
supportive
of
moving
these
things
forward.
Chin,
yes,.
G
You
go
from
Verisign,
I'm
thinking
about
the
future
of
the
document
and
the
potential
for
changes.
You
may
want
to
consider
relaxing
some
of
the
requirements
in
there
if
it
becomes
an
RFC
and
that's
something
which
is
required
becomes
optional.
Based
on
later
changes
in
policy.
We
wanted,
you
know,
have
to
kid.
You
are
so
yeah,
so
something
to
think
about
yeah.
So.
A
A
You
know
yes
take
the
time
to
give
it
a
review
and
make
sure
you
know
that
there
are
no
issues
with
it,
but
ideally
to
progress
this
along
pretty
quickly,
but
we
will
take
the
concrete
question
to
the
mailing
list
about
whether
or
not
to
drop
this
into
working
group
last
call
and
move
this
along.
Let's
see
if
any
showstopper
objections
come
up
on
the
mailing
list
and
get
everyone
involved.
A
A
Next,
up
on
our
agenda
is
the
our
DAP
documents,
so
Mario
yep
a
preference
in
what
order
Mario
or
can
I
just
bring
them
up
in
this
order
or
you'll
have
all
three
of
these
right.
You
have
a
preference
on
the
order
of
these
three
okay,
I'll
just
bring
them
up
in
whatever
order.
They're
here,
okay,
so
here
we
go
partial
response.
First,.
C
These
are
very
short
presentation
about.
The
progress
of
each
of
the
three
drafts
is
only
four
summarize
the
most
meaningful
changes
since
the
last
meeting
and
to
collect
possible
feedbacks
from
the
attendees
and
the
first
one
draft
is
passer
response.
Then
the
question
zero
one,
the
Russians,
you
know
one.
The
basic
field
sets
has
been
changed
from
required
to
optional,
so
their
implementation
now
is
considered
helpful,
but
not
required
to
improve
adapt
interoperability.
The.
C
C
A
C
The
change
is
shown
in
this
regard
about
the
sorting
of
pages
draft
in
the
version
0
1,
the
page,
a
metadata
object
has
been
simplified,
and
now
it
contains
only
a
free
free
members,
total
count
page
count
and
links
in
the
Russian
server
to
the
duality
between
offsetting
cuts.
Imagination
has
been
fixed
now
the
cursor
for
parameter
can
encrypt
above
offset
and
cut
some
pagination
information.
C
C
C
We
think
that
the
the
answer
is
no,
because
this
parameter
is
related
only
to
the
N
and
the
org
bukata
elements,
and
it
makes
sense
only
in
a
collection
of
of
jacquard
of
jacquards.
This
is
not
the
case
because
we
are
in
the
case
of
a
collection
or
objects,
including
jacquard,
could
a
possible
jacquard,
the
replacement
effect,
the
sorting
capability.
C
This
is
a
possibility
that
will
not
affect
affect
the
draft
because
the
they
are.
The
implementer
would
simply
need
to
change
the
Jews
apartment
member
in
sorting
method,
sorting
metadata,
so
he
can
change
the
representation
of
the
contact
information
and
simply
changing
the
the
department
member
in
soft
metal
metadata
212
to
maintain
the
correspondence
between
the
sorting
properties
and
the
the
jacquard
element.
C
C
Only
on
the
strict
control
and
only
to
users
who
are
legitimated
by
illegal
legal
basis
in
the
previous
consideration
section,
some
of
these
potential
users
are
supposed
are
reported.
I
think
that
probably
there
are
other
potential
uses
that
can
take
advantage
from
this
capability
and
are
legitimated
by
some
legal
basis.
These
are
just
to
refresh
the
current
path
available
for
for
this
capability
and
I
think
that
there
are
two
open
issues
to
tackle
one.
C
C
C
Marais
to
stand
the
the
possible
property
subject
to
reverse
search,
a
consequence
to
the
introduction
of
this
new
search
segment
path.
But
segment
is
if
we
should
opt
for
a
unique
path,
allowing
the
research
on
an
entity
detail
on
any
entity
details
so,
for
example,
the
previous
entity,
rental
or
entity,
F
and
search
path
segment
could
be
translating
into
new
search
with
the
same
sharing
the
same.
C
C
A
Ok,
ok,
just
to
put
these
documents
in
contact,
so
the
mic
is
open
now
for
any
questions
or
comments.
You
know
concerns
with
these
things
and
as
we
get
ready
for
that,
these
all
three
of
these
documents
are
new
features
and
enhancements
are
adapt
stuff
that
wasn't
there
before.
So
it's
important
to
take
a
look
at
them
and
consider
if
you
know
this
is
really
the
best
way
to
do
them.
A
From
the
point
of
view
of
this
working
group,
we
had
targeted
having
all
three
of
these
things
done
and
published,
pushed
out
the
door
by
the
next
IETF
in
November.
So
it's
important
to
keep
that
in
mind.
You
know
there
we
need
to
have
whatever
discussion.
We
need
to
have
about
moving
these
forward
and
I'll
observe
that
currently
it
looks
like
the
first
two.
The
sorting
and
searching
and
partial
response
do
seem
to
be
relatively
stable.
The
reverse
search
document
seems
to
have
just
some
open
questions
and
issues
here.
A
So
if
there
is
no
further
discussion
that
happens
on
the
partial
response
and
sorting
and
searching
they're
likely
to
go
to
last
call
sometime
relatively
soon,
we'll
we'll
push
through
the
data
escrow
things
first
and
then
we'll
be
coming
around
to
these
documents
and
look
to
move
them
along.
So
you
know,
please
do
take
the
opportunity
if
you
haven't
been
thus
far
to
give
these
documents
a
read
and
a
review,
and
you
do
consideration
to
whether
they're
ready
to
move
forward
or
not
and
with
that
the
my
clients
are
open.
So
please
great.
I
Thanks
thanks
Maria
for
doing
these
and
some
good
updates
in
this
recent
round.
My
thoughts
and
concerns
around
these
are
more
macro
not
related
to
the
particulars
of
either
searching
sorting,
partial
response
or
research,
but
more
that
from
an
industry.
Standpoint
are
standing
largely
in
stark
contrast
to
the
thing
that
Francisco
just
presented,
which
has
been
in
production
for
eons.
I
The
target
production
date
for
I
can
contracted
gTLDs
for
our
DAP
is
August
26,
as
many
processes
no,
and
so
our
gap
is
ramping
is
heading
towards
production
and
no
one
has
really
any
skin.
Not
knowing
operational
experience
at
scale
is
very
limited
across
the
industry,
and
I
would
offer
that
the
industry
in
itself
is
going
to
be
going
through
a
rapid
learning
curve
just
on
basic
our
GAAP
operations,
both
from
the
server
side
and
from
people
building
clients
against
that.
I
And
so,
while
these
features
that
we're
talking
about
are
you
know,
generally
interesting
and
certainly
applicable
and
I
think
are
going
to
happen,
might
be
concerned
about
the
entirety
of
them.
Is
that
implementations
are
going
to
be
evolving
very
very
rapidly
and
we
may
be
inadvertently
memorializing
into
an
RFC,
something
that,
with
some
implementation,
experience
is
going
to
be
subject
to
revision.
I
I
C
Aware
that
I
think
that
there
is
a
distinction
between
the
three
documents,
if
reverse
search
and
parts
partial
response
address
a
problem
that
is
common
to
every
rest
service.
Providing
data
so
I'm
quite
confident
that
this
solution,
we
will
not
be
encounter
any
issues
in
the
future,
any
particular
issues
in
the
future.
If,
if
we
now
release
this
document
as
as
RFC
in
the
in
the
short
term,.
C
C
To
moving
forward
this
dog
to
moving
forward
these
documents,
but
I
hope
that
there
will
be
other
feedbacks
coming
from
the
working
group
members
so
the
first
to
do.
The
first
two
documents
seems
to
me
more
stable
than
the
research,
so
this
this
is
why
I'm
thinking
to
to
ask
for
to
postpone
them
the
milestone
of
the
research
to
have
a
more
comprehensive
document.
A
Let
me
ask
a
clarifying
question
by
May
erectus
to
make
sure
that
I
heard
you
correctly
so
I
think
you
made
an
excellent
case
for
actually
pushing
out
the
current
milestones
for
these
documents
to
give
ourselves
a
chance
to
get
some
real
implementation
experience
with
them,
because
you
are
asking
a
very
valid
question
about.
Has
anyone
implemented
these
that
you've
interrupted
with
all
three
of
these?
Do
you've
done?
The
implementations
has
anyone
else,
maybe.
C
A
A
I
K
I
C
A
K
I
think
your
point
here
remember
not
having
different
types
is
a
good
one.
I
think
it
should
be
a
string
in
all
cases
like
you
said
it
just
will
make
things
easier
for
implementers
more
generally
on
the
responses
that
this
I
think
one
of
the
issues
that
effects
both
reverse
search
and
sorting
and
purging
is
the
CC
and
country
name
issue.
You
might
have
one
server
that
publishes
country
one,
so
the
publishes
CC
one
does
both
different
parameters
etc.
K
C
C
Provide
CC
as
a
sorting
property,
because
CC
is
the
element
that
the
other
server
returned
returns.
So
in
the
case
of
reverse
search,
you
are
searching
for
something
connected
to
the
country.
So
if
you,
if
you
for
example,
if
you
declare
cc
equal
Italy
I,
my
other
server
can
transform
this
information
as
something
to
to
match
in
the
my
in
the
country-
information,
oh
yeah.
So
if
I
have
country
name,
I
I
will
search
for
Italy.
If
I
am
the
country
code,
I
will
search
for
da
TT
because
it
is
a
search.
C
Define
an
S
and
explicit
mapping
I
want
to
to
define
a
semantic
equivalence
between
the
concept
or
between
the
country
code
that
it
is
reporting
in
in
in
the
query
and
the
information
I
have
on
the
underline
DBMS.
So
I
think
the
implementers
should
be
free
to
map
this
information
on
his
information.
C
If
he,
if
he,
if
the
country
name
is
available
instead
of
country
code,
they
will
map
the
country,
the
the
information,
the
Queen,
so
the
country
code
I-I-I-t
to
the
country
name
Italy,
okay,
just
to
not
lose
to
to
to
not
lose
a
relevant
information
and
to
provide
as
many
results
as
possible,
which
are
relevant.
Okay.
C
A
B
M
We
got
in
there
we
go
so
developed
I.
Don't
think
that
it
should
be
as
a
working
group
tied
to
like
an
policies,
because
aldub
is
also
used
by
a
CCT
ID
by
VG's
twist.
So
so
it's
not
a
problem
for
me
if
we
move
forward,
but
but
there
is,
of
course,
a
big
problem
with
piracy
issues
because
of
the
power
we
must
search,
you
can
find
a
lot
of
things.
M
As
you
didn't
know,
the
fact
that
you
can
get
information
about
the
domain
coca-cola
dot-com
does
not
mean
you
have
a
right
to
know
all
the
domains
registered
by
the
coca-cola
company
and
it's
even
worse
for
individual
users,
of
course.
So
this
has
been
discussed
already
in
Dragon
as
final,
but
I
don't
see
any
progress
on
that
the
current
privacy
considerations
could
be
exactly
the
same
for
the
ordinary
held
up.
There
is
nothing
new
in
it.
Just
saying
that
it
should
be
done.
You
know
foodway,
which
is
quite
obvious.
All
of
us
share.
M
C
C
We
are
talking
about
something
that
has
been
overcome
in
from
the
technology
from
by
the
technology.
In
the
reality,
there
are
some
services
available
on
the
Internet.
You
can
do
the
reverse
series,
and
probably
in
the
future,
you
you
you
will
you
you
are.
You
will
have
the
possibility
to
reverse
a
tap
for
money
and
these.
M
A
Good
question,
though,
and
and
a
good
point
which
really
we
do
need
more
discussion
on
the
mailing
list.
There
is
a
distinction
between
you
know,
privacy
policies
and
the
effect
on
what
the
protocol
does
so
having
a
protocol
which
defines
the
right
way
to
do
things
and
then
in
the
privacy
considerations.
We
just
need
to
call
out
that
you
know
there
are
policies
that
are
going
to
affect
us,
but
we
should
have
more
discussion
about
this
on
the
list
and
what
we
need
to
put
in
these
privacy
consideration
sections
for
this.
These
droughts
I
agree.
M
A
O
E
O
The
I
can't
should
not
be
the
gating
factor
for
for
this
first
off
the
I.
Can
it's
not
one
of
one
mind
about
anything?
The
TS
she
actually
pointed
out.
The
reverse
search
draft
is
something
that
it's
needed.
So
that's
part
of
ICANN,
that
was
an
I
can
group
just
because
the
policy
people
and
their
expedited
status
aren't
really
doing
anything.
O
C
A
A
clarifying
question,
then
so
Rick
was
was
kind
of
making
the
case
earlier.
You
know,
delay
publication,
but
I
hear
you
pointing
out
that
Rick's
argument
was
was
based
in
part
on
deployment
at
scale
and
what's
going
on
in
the
gTLD
space,
but
you're
sort
of
arguing
the
other
side
of
that's,
not
the
only
customer
Eric.
So
maybe
we
shouldn't
gate
based
on
that
is
that.
O
J
I
Thanks
I'm,
not
quite
as
crisp
as
Peter,
this
brick
wall
and
so
to
be
clear.
It's
not
just
I
can
policy
that
I
was
talking
about
its
yes,
the
I
can
policy.
There
is
incorporating
particular
privacy
restrictions
that
are
be
that
have
been
put
in
place
by
the
GD
P
R.
So
that's
the
issue
of
I
camp
policy
that
so
just
to
be
clear.
It's
not
that
this
group
should
be
beholden
I
can't,
but
that
the
GD
P
R
is
rippling
into
I
camp
policy,
which
is
causing
a
bunch
of
changes.
I
I
A
If
I
may,
I
want
to
I'm
gonna,
try
and
frame
that
back
and
actually
make
it
even
more
general,
we
did
say
just
a
little
bit
ago
and
it
is
true,
you
know,
Spain's
got
us
on
this
discussion.
We
really
do
need
to
have
a
better
privacy
discussion
about
what
goes
in
these
drafts
and
for
the
privacy
considerations,
and
we
need
to
address
that
much
more
carefully.
A
It's
you
know,
GDP
are
I,
can
might
be
principal
motivating
factors,
but
it
really
does
need
to
be
a
general
discussion
about
privacy
and
its
effect
on
this
registration
data
in
general.
In
all
of
the
context
in
which
it's
used.
So
that's
definitely
a
discussion
to
take
to
the
mailing
list
on
these
documents.
G
A
That,
actually
is
a
something
that
we
should
do:
I
to
mention
that
earlier,
thanks
for
that
Jim,
when
we're
when
I
was
asking
you
before
about
whether
there
were
implementations
other
than
your
own,
we
should
add
that
section
into
the
draft
so
that
it's
there
and
things
and
get
that
on
record
as
we're
going
forward.
Okay,
so,
okay,
any
other
questions
or
comments
were
a
little
bit
ahead
of
schedule.
So
we
have
time
go
ahead.
P
One
of
the
struggles
I
always
have
a
running
an
implementation
status
section
is
my
lack
of
knowledge,
of
what
other
people
are
doing
right.
So
it's
okay
to
sit
here
and
say:
hey
Mario
put
this
text
in
there.
He
can
document
is
implementation
experience.
But
if
you
have
implemented
these
drafts,
please
let
Mario
know
right.
So
it
makes
his
job
easier
to.
A
In
point,
I
know
excellent
point.
Thank
you
for
that.
Okay,
quick
recap.
Just
keep
in
mind
the
first
two
documents,
we're
thinking
or
relatively
stable,
except
now
for
dealing
with
privacy
considerations
and
implementation
status
and
and
the
regex
weekly.
We
have
some
additional
discussion
we're
going
to
have
here
on
some
issues
on
the
mailing
list.
But,
okay,
you
know
please
do
come
into
the
list.
Thank
you
all
for
your
comments.
A
Q
Be
nice
about
that,
but
please
go
ahead.
Hi
George
here!
This
is
a
very
quick,
no
slide
talk.
It
is
too
soon.
It
is
too
soon
to
answer
this
question
because
we
own
the
end
to
this
phase
of
operation.
Correct
me,
if
I'm
wrong
one
ietf
ago,
I
think
we
we
decided,
we
would
have
this
model
in
Prague.
Didn't
we?
Yes,
yes,.
Q
Hoping
what
I'm
trying
to
do,
Here
I
am
NOT
trying
to
wreck
the
joint.
What
I
want
you
to
do
is
I.
Want
you
to
keep
in
mind
this
question:
does
the
model
work
because
I
think
we
are
going
to
want
to
review
this,
probably
in
two
or
three
ietf
time
so
I'm
putting
this
on
the
table
now
so
that
we
start
thinking
now?
Is
this
producing
a
pace
of
work
which
works
for
us?
The
reason
I'm
doing?
Q
That
is
because
the
two
document
model
it
feels
to
me
has
potential
to
create
a
risk
and
an
example
of
this
would
be.
We
have
here
or
document
have
substance,
the
reverse
search
document,
and
we
now
have
a
massive
issue
of
substance,
the
privacy
issue
and
it's
effectively
going
to
block
this
is
going
to
be
something
that
I
would
believe
you
and
Peter
reasonably
are
going
to
say
it's
not
tenable
to
progress.
Q
This
work,
if
we
do
not
adequately
address
a
significant
privacy
and
policy
issue,
and
so
we're
going
to
wind
up,
probably
and
I,
know
I'm
predicting
a
chair
behavior,
but
the
probable
outcome
is
a
substantive
document
and
privacy
is
going
to
appear
and
it's
going
to
be
a
blocker
for
a
reverse
search
draft,
which
means
we're
going
to
stack
another
document.
On
top
of
the
document
stack,
we've
got
and
the
to
document
pace
we're
not
going
to
progress
these
documents.
So
there's
a
process
aspect
of
necessarily
discovering.
Q
We
have
big
work
to
do
and
all
I
wanted
to
do
a
my
stress.
I
am
NOT
trying
to
wreck
the
joint.
All
I
wanted
to
do
is
say
start
thinking
now,
because
this
is
going
to
come
back,
probably
in
two
or
three
IETF
time.
Is
it
working
that
was
it
questions
discussion?
Whatever
the
chair
lets,
you
do
dancing
lessons.
D
D
Deep
one
of
the
reasons
that
you
have
this
is
ad
communication
with
the
ad
VAD
asking
you
to
gain
your
work
and
not
dump
everything
in
so
what
I'll
say
about
that
is
that
if
unexpected
things
come
up
and
you
suddenly
realize
you
need
to
do
something
new
that
blocks
other
South
I'm
going
to
be
flexible
about,
allowing
that
to
come
into
the
stream
I'm,
not
going
to
stand
here
and
say
no
you're
already
full.
You
already
have
all
the
documents
you
can
handle
we're.
D
Q
O
O
A
This
is
a
let's
see.
The
Charter
does
have
us
working
in
both
of
these
areas,
so
this
is
just
a
functional
implementation
of
being
allowed
to
work
in
both
of
those
areas,
and
we
worked
this
out
with
the
area
director
in
March.
We
just
kind
of
proposed
hey.
Let's
do
this
and
we
kind
of
had
a
verbal
consensus
from
those
in
the
room
and
no
no
objections.
I'm
hairless.
O
O
Has
to
be
the
Charter
I,
don't
be
hi
ceremony
about
this,
but
just
some
place
that
people
can
refer
to
it,
because
when
I
was
just
like
model
again,
because
I
could
barely
remember
from
Prague,
so
if
we
could
have
them
running
down,
someplace
that's
easily
accessible,
I
think
would
be
great.
That's.
Q
A
Thanks
for
listening,
okay,
No,
thank
you
George!
It
is
actually
a
valid
question
to
ask.
You
know
whether
whether
the
way
in
which
we're
working
is
working
and
that's
important,
and
it's
useful
and
I'm
glad
that
he
raised
the
question
and
yes,
we
should
write
this
down
and
document
it
and
and
think
about
it,
and
and
after
we've
done
this
a
couple
of
meetings
or
at
least
for
a
year,
so
maybe
next
March.
A
We
should
make
a
point
of
bringing
this
question
up
again
and
sync:
that's
working
for
us,
so
we
had
some
good
motivation
and
reasons
for
creating
this
model
and
just
something
to
try.
So
we'll
see.
Okay
with
that
me
pause
for
a
moment
to
introduce
this
idea
of
new
work
and
and
what
it
means.
The
reason
why
this
is
on
here
is:
yes:
we
have
a
couple
of
documents
that
are
in
isg
evaluation.
We
have
several
documents
which
are
targeted
ideally
to
be
pushed
out
for
publication
before
the
end
of
this
year.
A
So
before
the
next
IETF
meeting,
we
have
a
set
of
documents
that
we're
looking
to
move
along,
and
that
opens
up
opportunity
for
us
to
consider
new
work.
It
is
true
that
we
have
quite
a
backlog
of
a
dozen
and
a
half
or
so
documents
that
are
potential
for
moving
forward.
This
is
just
another
set
of
things
to
put
in
the
mix
for
us
to
think
about.
So
we
have
a
few
people
with
some
suggestions
that
we
want
to
put
on
the
table.
A
The
have
not
been
adopted
by
the
working
group
yet,
but
we're
putting
them
out
there
for
consideration,
because
at
some
point
here,
as
we
move
between
November
and
March
IETF
meetings,
we're
gonna
have
to
be
thinking
about
which
documents
do
we
want
to
pull
up,
to,
adopt
and
add
to
our
milestone
list
to
go
forward.
So
we're
gonna
add
these
to
the
mix
as
well
as
all
of
the
other
ones
that
we
have
okay.
A
So
this
is
just
calling
them
out
for
people.
So,
let's
move
through
them
here,
first
thing
you're
actually
going
to
do
is
this:
is
we
put
it
under
new
work?
But
mark
you
want
to
come
up
and
talk
about.
What's
going
on
with
our
DAP
deployment
and
findings,
Mark's
been
keeping
quite
a
good
document
going
for
us
here.
L
Good
morning,
I'm
not
blushing.
This
is
about
a
position
about
this
draft,
so
all
the
details
are
there.
The
context
of
this
draft
is
that,
while
developing
various
tools
and
in
my
team
and
myself
related
to
our
adapt,
so
client
servers
and
confirm
installs
with
found
many
issues
in
the
field,
some
may
have
been
corrected.
Hopefully,
but
the
reality
is
not
that
much
all
the
information
about
the
guilty
yard.
L
L
L
L
There's
a
it
seems
to
be:
there's
a
need
for
a
registry
entity
that
is
not
yet
model
or
identified,
for
example,
in
the
u.s.
we,
the
registry
itself,
is
identify,
while
in
the
air
adapter
sponsor,
does
it's
not
identified
itself
and
that's
could
be
for,
for
example,
providing
info
about
the
registry
website,
for
example.
L
Another
case
we
found
is,
while
we
are
working
with
Diana,
is
to
have
a
downstream
registry,
for
example,
if
that
you
request
in
the
Ayana,
our
dev
server
will
actually
answer,
for
you
know
calm,
but
calm
would
actually
you
know
in
the
response
we
should
actually
say
this
is
the
our
dev
server
of
that
TLD
right?
That
model
is
not,
it
doesn't
exist
actually
in
air
Deb.
Should
it
be
a
rare
down.
C
L
L
I
can
are
that
technical
implementation
guide
and
response
profile
are
been
registered
and,
as
you
see,
there
are
some
kind
of
a
confusion
on
you
know
0
or
level
or
version
and
stuff.
So
I
guess
we
need
probably
to
update
the
spec
to
make
it
here.
What
what's
the
actual
usage,
because
it's
just
by
seeing
the
values
in
the
field.
It.
B
L
L
All
kinds
of
things
that
I've
seen
in
JSON
responses
object
last
name
empty.
We
seen
other
things,
links
relation
values,
different
things,
including
a
URL
which
is
completely
buggy,
but
those
seems
to
be.
If
you
look
at
the
registry
for
links,
relations,
there's
like
thousands
of
them
being
different
defined
with
no
real
semantics
being,
you
know
actually
clearly
defined
so
it
it
appears
to
me
that
people
are
just
you
know,
picking
one
and
and
then
we
all
will
kind
of
losing
semantics.
L
L
C
L
What
mitigation
maybe
to
update
the
RC
pretty
bit
this
case
and
I'll,
give
a
little
bit
more
details
at
the
end,
for
you
know
what
we
could
do
for
a
client.
If
you
send
me
a
link
without
a
rail
I
have
no
idea
what
to
do
with
this
thing.
You
know
what
is
this
right?
How
do
I
show
it?
What's
the
semantics
between
this
link,
we
could
update
the
RFC
that
says,
you
know
require
value.
The
Creator
see
especially
response
is
pretty
nice.
You
know,
there's
no
requirement.
L
No,
you
know
you
can
do
almost
anything
well,
okay,
so
therefore
they
may
be
compliant,
but
that
doesn't
tell
me
anything
for
the
client
site.
So
we
might
like
to
tighten
a
bit
the
RFC
or
another
possibility
at
the
end.
I
was
thinking
was
maybe
to
have
a
BCP
like
you
know
that
says
you
know
you
should.
While
the
RFC
says
you
know
you're
free
to
do
this,
you
know
you
may
prefer
to
do
this,
the
BCP
being
generic
for
not
related
necessarily
to
I.
L
F
L
In
the
URL
well,
the
self
actually
should
be
the
kind
of
the
unique
you
know
identifiers
for
this
object,
but
the
queries
could
be
a
mix
of
you
labels
or
a
labels
right.
So
you
know:
what's
what's
the
policy
right?
So
what's
the
real
thing
and
the
this
actually,
this
server
was
actually
reporting
the
self
differently
for
the
same
object,
depending
on
the
query,
so
so
I
think
again
that
the
specification
could
be
a
bit
more
tightened
and
saying
you
know
for
the
self
always
return
the
a
labels
or
like
that.
L
C
L
To
me
about
registrant,
which
is
within
the
entity
of
abuse,
not
makes
any
sense
to
me
but
URL
encoding,
so
this
is
actually
from
the
one
of
the
are
our
because
that's
the
only
one
that
has
Collins
in
the
URL
for
request.
So
when
a
dir
server
actually
accepted
the
first
one,
but
decline
rejected
the
second
one,
because
it
was
person
decoded,
I,
think
I've
been
into
the
our
season.
L
It's
probably
legitimate,
but
not
nice,
for
the
clients,
because
some
clients,
library,
is
just
you
know
personally
encode
as
soon
as
there's
kind
of
a
you
know,
strange
character
in
it
and
because
the
bad
thing
of
URLs
and
schemas
is
that
the
depend
on
the
which
scheme
the
processing
of
the
of
the
right
side
of
the
scheme.
It
can
be
different
so
anyway,
so
I
think
that
would
be
a
right
thing
to
do
yeah.
L
So
this
one
is
interesting.
I've
seen
different
uses
of
rel
equal
related
and
the
ICANN
are
that
profile
actually
says.
This
is
the
link
to
the
essentially
the
registrar
server
to
get
the
registrant
information.
However,
I've
seen
other
use
of
related,
which
is
related,
means
something
larger
than
just
registrar
server.
L
Therefore,
there's
a
kind
of
a
ambiguous
semantics
unrelated
so
I'm
not
sure
what
to
do.
I
guess
the
ship
as
the
train
already
gone,
but
maybe
something
like
a
new
realm
that
would
be
registrant
info
would
be
more
appropriate,
but
I'm
not
sure
what
to
do
with
this
one
search
for
things
that
are
not
so.
This
is
a
reported
to
the
two
others
of
RFC.
L
L
Seen
in
the
field,
the
right
side,
they
I,
don't
know,
I.
Think
it's
an
easy
developer.
I'm!
Sorry,
if
you
are
the
person
here,
but
this
one
is
the
address
and
we
just
put
an
arrow
while
there's
nothing
to
put
in
the
area,
so
it
could
be
just
you
know
coke
right,
but
they
put
an
arrow
with
empty
in
it.
So
you
know
I
need
to
on
my
client
site
to
actually
look.
L
L
L
What
people
were
saying
is
is
just
too
much
and
that
needed
we
should
have
only
one
and
it
should
be
HTTPS
I,
don't
know
what
to
do
is
kind
of
bit
late
now,
but
that's
what
it
is
Bertrand
status.
So
the
document
contains
obviously
ephemeral
issues.
You
know
bugs
and
implementations
that
should
be
solved,
hopefully
values
to
be
registered
in
Ayana.
So
that's
something
that
should
disappear.
Obviously,
but
I
still
think
and
I've
seen
some
people
fixing
the
the
bug.
L
The
eff,
as
this
show,
though
so
I
think,
there's
a
value
of
the
document
as
it
goes.
There
are
recommendations
to
specifications,
discussion,
points
on
all
to
improve
and
other
topics
I
recently
discovered
and
haven't,
got
time
to
document,
publish
so
two
things
we
could
do
with
this
document.
Just
let
it
go
continue.
Should
working
group
decide
to
update
the
specs,
then
there's
some
recommendations
there.
L
If
we
agreed
to
be
followed
in
happy
to
start
working
on
this
or
if
the
authors
want
to
do
whatever
my
my
idea
is
to
that
it
could
become
a
BCP
by
having
you
know,
you
know
best
current
practice
on
things
that
you
should
do
and
not
do
and
remove
all
the
ephemeral
issues
that
are
gone.
So
that's
my
presentation.
A
Let
me
first
start
just
by
thanking
you
Mark
for
for
doing
this.
I'm
sure
you've
heard
that
many
times
from
others
who
were
on
the
receiving
side
of
your
having
gone
through
and
done
this,
but
really
quite
a
just
an
enormous
piece
of
work
and
very
happy
that
you
did
this.
So,
let's
sum
quite
a
few
go
in
here:
let's
go
down
the
list.
O
This
is
awesome,
I
think
your
group
should
do
something
with
it
on
BCP
whatever,
but
this
is
exactly
the
type
of
thing
the
IETF
should
be
doing
so
hopefully
we
continue
down
that
road.
I,
don't
know
why
people
aren't
registering
there,
tensions
with
Diana
I
think
maybe
two
designated
experts
or
jerks
I
don't
know.
R
O
I
know
there's
some
sort
of
other
hang
up
in
the
ion
or
registration
process.
That
would
be
interesting
to
know
as
far
as
the
fifty
I
think
it's
5840
links,
registry
or
whatever
that's
a
very
good
I.
Thank
you
for
pointing
that
out.
That's
kind
of
a
there's,
a
lot
of
confusion
around
that
and
I
personally
have
never
registered
anything
in
there
and
I.
Don't
know,
I'm,
not
sure
what
the
process
is
so.
K
L
Exactly
the
point
that
maybe
it's
not
a
real,
you
know
RFC
protocol
standard,
but
the
BCP
would
fit
well.
You
know
with
in
there
that
you
know,
here's
the
you
know,
values
and
semantics.
We
understand
and
we
you
should
do
those
kinds
of
things
instead
of
using.
You
know
weird
link
values,
for
example
yeah,
so.
O
O
The
other
thing
is:
is
that
this
isn't
in
the
document
there
are
several
people
who
created
tools.
Aaron
has
tools,
a
peanut
has
tools,
you
have
tools
and
I,
don't
know
why
people
aren't
using
them
to
validate
their
servers.
So
maybe,
if
we
should
maybe
that,
in
a
section
in
the
documents
saying
by.
O
M
C
P
But
a
couple
of
additional
points
with
respect
to
the
extension
stuff
I
have
to
admit,
even
though
I
know
I'm
one
of
the
guilty
parties
who
is
responsible
for
writing.
That
document,
when
I
wrote
the
object,
tag
draft
which
had
a
requirement,
you
know
to
add
a
new.
Our
data
conformance
value,
I
was
looking
at
74,
83
and
I
have
to
admit.
I
was
confused
because
there
are
places
where
it
uses
examples
of
a
string
like
lunar
Nick
and
in
other
places
it
uses
lunatic
level,
zero,
yeah.
C
P
I
Thank
you,
Rick
great
thanks,
I'm
critical
embarrassin
tactical
thing
you
mentioned
in
here
the
course
requiring
the
course
with
a
train
to
get
to
a
must
in
the
heart
out
and
profile.
That's
used
in
the
gTLD
space
that
there
is
a
item
in
there.
That
requires
it
to
be
a
must,
as
general
agreement
yeah.
I
General
I'm,
just
for
people
that
are
that
don't
know
marks
IETF
regex
document
has
been
getting
a
lot
of
air
time
and
attention
in
the
in
an
ardent
group
that
meets
basically
weekly
ICANN,
accredited
registrar's
and
registries
that
are
that
are
doing
our
dad
implementations.
And
so,
while
it's
getting
some
attention
here
is
getting
a
lot
of
attention
live
in
a
community
that
communities.
It's
certainly
thankful
appreciative
to
all
the
work
that
mark
has
done
in
regards
to
documenting
these
problem.
Yeah.
L
Well,
just
to
respond
to
that
I
think
there's
like
fixture
bugs
kind
of
issues
and
also
in
in
the
same
document,
which
is
okay,
I
think
for
now,
but
at
the
end
we'll
have
to
you
know:
cleaning
up
is
you
know,
recommendations
for
you
know
new
versions
of
specs
or
maybe
BCP
deployment,
and
you
know
there's
a
mix
of
different
things,
but
I
hope
that
they,
but
you
know
I
can
community
will
actually
fix
the
bugs,
at
least
so
those
will
disappear.
I
G
It's
Jim
goes
embarrassing.
Rick
just
stole
my
thunder,
I
was
gonna,
call
them
and
type
I
really
support
the
work.
I'm
sure
the
registers
would
have
really
appreciated
this,
for
you
can
be
the
way
that
I
process
this
particular
documents.
I,
looked
at
things
that
work
when
I
consider
implementation
issues
of
specifically
publication
issues,
we're
on
our
issues
as
well
as
like
RFC
no
feedback.
So
if
they're
I'm
not
sure
how
you
even
categorize
those
things.
L
R
R
The
status
track
document
so
terrific,
if
I,
can
help
with
that
in
any
way
as
a
participant
in
the
former
Terra
weirds.
Please.
Let
me
know
one
thing,
though,
as
I
skim,
the
Charter,
the
Turner
doesn't
talk
about
modifying
those
you
might
have
to
tweak
it.
If
you
need
help
radio
chatter
text
help
do
that
excellent
assistant
movie
this
long
as
much
as
I.
Can
that's
not
what
I
said.
L
That's
an
come
time.
L
I-I-I,
I'm
not
sure
at
the
moment
I
was
more
kind
of
raising
the
issue.
You
know
either
way.
I
don't
know
I'm.
Obviously,
if
it's
the
link
relation
type
registry
to
fix,
then
dad
discussion
should
probably
be
somewhere
and
art.
You
know
Aria
somewhere,
but
or
HTTP
I,
don't
know,
but
I
I
don't
have
a
good
suggestion
at
the
moment.
I
was
more
reasoning.
The
issue
in
see
you
know:
where
is
the
right
place
to
do
in
some
ways
this
you
know
the
registry
itself
is
full
of
stuff.
L
M
Because
I
wasn't
the
impression
that
the
client
was
right
in
using
us
in
some
coding
on
one
of
the
point
of
other
is
that
we
rely
on
HTTP,
so
we
we
use
everything.
We
don't
have
to
define
everything
by
ourselves.
We
just
say:
okay,
look
at
the
UI
spec
of
the
HTTP
spec,
so
it
is
it
really
so
ambiguous
in
the
you
are
your
eyes
back.
L
L
That
was
no
fun
so
anyway,
I'm
just
saying
you
know,
both
both
kind
of
queries
should
be
supported
by
all
servers,
because
client
lives
often
do
kind
of
a
to
escape
of.
If
this
is
scheme
number
one,
then
I
should
percent
and
code
only
these
characters,
and
if
it's
scheme
number
two
percent
and
kind
of
the
other,
you
know
characters.
The
lips
are
just
lazy.
You
know
whenever
there's
you
know
almost
on
ASCII
things
percent-encoded
all
the
time.
L
O
L
G
Thank
you
so
yeah
this.
This
draft
was
recently
published
and
its
primary
purpose
is
to
address
the
increased
dependency
on
the
authorization
info
value.
In
essence,
the
the
goal
here
is
to
provide
a
more
secure
way
of
managing
the
authorization
info
while
using
the
existing
features
within
the
EPP
rfcs.
But
what's
out
of
scope
in
this
is
the
transfer
process
policy,
things
like
the
form
of
authorization
or
the
the
implementation
of
an
immediate
transfer
or
even
defining
the
concrete
time
to
live
for
an
authorization
info.
G
So
the
elements
of
this
draft
include
three
different
things.
The
first
thing
is
the
use
of
a
strong
random
authorization
info
value.
The
reality
here
is
that
the
this
is
a
generated
value
and
to
increase
the
security
is
to
ensure
that
we
have
the
appropriate
level
of
randomness.
Specifically,
the
recommendation
is
128
bits
of
entropy
for
the
value.
The
good
news
is
the
fact
that
the
epp
RFC
doesn't
have
any
length.
Restrictions
for
the
authentic
in
element
is
to
make
the
auth
in
fort
lid
to
be
able
to
do
that.
G
The
server
needs
to
be
able
to
allow
for
them
to
be
unset.
Many
service
a
day
don't
do
that,
but
the
RFC
does
in
fact
support
the
unset.
You
know
the
authorization
info.
The
other
thing
is
that
the
the
authorization
intro
would
only
be
set
during
the
transfer
process.
So
therefore,
there's
no
need
for
an
authorization
info
unless
there's
actually
a
transfer
that
is
occurring.
The
other
item
is
to
be
able
to
support
a
TTL
that
his
client
managed.
G
In
essence,
the
registrar's
would
have
to
keep
ability
to
be
able
to
find
what
that
time
of
live
is
and
use
the
features
of
the
server
to
be
able
to
unset
it
when
that
TTL
expire,
so
the
more
the
critical
the
domain
name,
the
lower
the
TTL
would
be,
and
then
the
last
islands
storage,
specifically
whether
or
not
the
authentic
should
be
stored
in
the
registrar.
If
it's
stored
in
the
registry
how
it
should
be
stored.
The
recommendation
out
of
this
graft
is
that
the
Registrar
does
not
store
the
value
at
all.
It
generates
it.
G
It
provides
it
to
the
Registrar
and
there's
no
need
to
storage,
so
there's
no
risk
of
somebody
within
the
registrar
having
access
to
that
value.
Additionally,
in
the
registry,
it's
the
store
it
even
in
one
way
hash,
so
similarly,
there's
less
risk
of
somebody
being
able
to
have
access
to
that
authorization
info
value.
G
So
if
you
go
by
this
operational
practice,
these
are
the
steps
for
a
transfer.
It
first
starts
out
with
a
create,
so
the
domain
has
to
be
created
during
the
create.
The
authorization
info
would
be
passed
as
an
empty
value.
There's
no
need
for
the
authorization
info
at
the
time
create
because
there's
no
transfer
when
the
registrant
wants
to
transfer
what
they'll
do
is
they'll
go
to
the
losing
registrar,
which
will
then
generate
a
strong
random
value.
G
The
Registrar
will
provide
it
to
the
Registrar
and
also
pass
it
through
the
registry
which
will
store
it
as
a
one-way
hash.
Then
what
will
happen
is
that
the
registrant
will
go
to
the
gain
registrar,
provide
the
authorization
info,
which
will
then
be,
can
be
pre
checked
using
the
info
command,
which
accepts
the
authorization
info,
and
then
they
can
go
ahead
and
submit
it
with
the
transfer
request,
which
the
registry
will
hash.
It
compare
the
hashes
if
they're
match,
then
it's
all
good.
G
The
last
thing
is
when
the
transfer
successfully
goes
through,
the
registry
will
auto
unset
it.
So
in
essence,
it's
like
a
create,
so
a
transfer
process
is
complete
and
the
registry
can
go
ahead
and
auto
clear
it.
So,
in
looking
at
the
epp,
RFC's
I
wanted
to
see
whether
or
not
the
RFC
supported
what
was
defined
within
this
practice.
The
first
thing
is
to
be
able
to
create
with
the
empty
auth
info
it
can.
G
So
the
fact
that
matter
is
that
there's
no
length
restrictions
on
the
auth
info
there's
an
ability
to
be
pass
an
empty
value
which
allows
us
to
feel
support
this.
The
next
is
the
ability
to
be
unset
the
auth
info.
It
just
happens
that
there's
two
different
ways
to
do
this
in
the
domain
RFC.
It
actually
has
an
explicit
element
to
be
able
to
unset
the
author
for
it's
called
domain
norm.
G
I'm,
not
sure
if
you
know
about
that
element,
I
found
that
out
and
then
there's
the
other
way
where
you
can
just
pass
the
MPE
domain.
Pw
element.
The
contact
RFC,
which
also
has
authorization
and
fill
values,
does
not
support
the
corresponding
contact
element
and
then
the
next
is
to
be
able
to
update
and
use
a
strong
offense
Oval.
You
again,
there's
no
restrictions
on
length.
There
is
an
issue
related
to
inclusion
of
a
space
in
the
random
value.
G
It
just
happens
that
whitespace
is
replaced
in
the
external
parser,
so
it
might
be
a
good
idea
not
to
include
the
space.
The
last
thing
is
that
if
the
registry
is
storing
it
as
a
one-way
hash,
they
cannot
return
the
value
in
the
info
response.
That
is
an
optional
value
in
the
epp
RFC.
So
it
can
be
a
can
be
supported.
D
D
G
F
H
Okay
sure
hit
the
last.
Is
your
implementation
allowed
to
register
on
saying
that?
What
doing
the
create?
Can
you
keep
me
in
focus
having
dead,
I
think
that
the
register
on
have
disadvantage,
because
for
the
time
that
you
want
to
transfer,
he
had
to
contact
the
losing
that
just
drop
at
that
time.
I
don't
know
that
because
I
want
to
transfer
without
do
it
they're
losing
register
and
also
I
know
it's
an
implementation.
H
People
have
to
do
it
can
do
or
not,
by
just
thinking
that
a
register
on
on
appeal
that
would
be
using
my
disadvantage.
Yeah
I,
didn't
know
I'm
saying
you
say,
there's
a
disadvantage
to
manage
because
as
a
registrant,
when
I
created,
my
name,
I
would
like
to
get
my
info
so
anytime
a
lot
of
times,
but
I
can
do
it
well.
P
P
We
don't
allow
the
registrar
to
set
up,
and
we
generally
don't
like
to
give
them
the
off-color
on
registration,
because
the
domain
can't
be
transferred
for
60
days.
This
is
for
GTA
news
anyway,
and.
J
P
Don't
it's
a
risk
to
have
that
off
code
out
there
and
have
the
customer
forget
that
they
actually
happen
and
it's
in
an
email
somewhere
the
email
gets
hacked
and
the
domain
is
gone
because
they
had
so
it's
something
that
we'd
like
to
see
the
auth
code.
Don't
don't
ask
for
it
until
you're
ready
to
transfer
so
that
it's
out
there
for
just
a
little
bit
amount
of
time
that.
K
Okay,
so
this
is
about
a
profile
for
Jacob.
There's
been
a
fair
amount
of
criticism
of
Jacob
from
implementers
on
both
the
server
side
and
client
side.
Some
of
that
is
about
the
structure
of
Jacob,
particularly
its
use
of
arrays
for
things
like
attributes
and
also
for
delivery
addresses
the
structured
part.
K
K
K
If
this
is
enough
to
head
off
switching
formats,
though
the
list
traffic
today
indicates
that
it
probably
isn't
in
the
event
that
it
is,
does
anything
else
need
to
be
included
and
then
at
a
more
general
level.
If
people
are
concerned
about
free
cards
complexity,
but
perhaps
not
interested
in
the
profile
approach,
do
we
need
to
discuss
getting
more
and/or
better
check
our
libraries
for
implementers
thanks.
C
G
O
And
you
need
I
support
and
actually
come
to
figure
out
how
to
do
the
best
we
can
with
J
card.
At
the
moment
we
already
have
many
people
who
have
implemented
J
card
I've
done
it
four
times
already.
So
we
there's
plenty
of
deployment
of
this
yeah
J
card
is
screwy,
but
it's
not
that
scurry
I've
come
across
worse
things
in
the
ietf,
much
worse
things
and
to
be
honest,
as
far
as
they
are
tobiko
systems
go
I.
O
Think
the
bootstrap
registries
are
far
more
structurally
unsound
than
then
J
card
is
so
the
I've
I
favor
just
trying
to
go
forward
with
J
card.
The
only
and
I
will
note
that,
having
been
on
both
sides
of
the
communications,
both
as
a
server
and
a
client
for
servers,
it's
not
that
it's
it's
hard
to
interpret
the
RFC
sometimes,
but
once
you
get
it,
you
got
it
it's
the
clients
where
it
really.
It
really
is
problematic
and
that's
where
profile
will
help.
O
U
Knew
Jenkins
I
can't
comment
on
whether
it's
suitable
or
not
I've
been
involved
with
it.
J
s.
Contact
at
Owens
wanted
a
few
quick
comments
on
that
two
things.
Firstly,
one
of
the
explicit
goals
is
that
it
well
being
fully
featured
it
scales
for
simple
use
cases
to
be
really
simple.
It
should
appear
simple
if
you're,
only
using
a
few
bits
of
it,
we
J
as
calendar,
which
is
the
kind
of
iCalendar
equivalent
of
this,
is
in
last
call
Norma's
published.
That
perhaps
gives
you
a
better
idea
of
how
that
works.
U
If
you're
creating
very
simpler,
then
it
looks
super
simple.
It's
real
easy
to
use.
We
one
of
the
problems
with
things
like
gay,
Cal
and
J
card
is
even
the
simple
stuff
it's
horrendous
to
work
with
them,
not
the
way
anyone
uses
JSON
outside
of
those
systems.
So
in
that
respect,
your
body
were
good.
Having
said
that,
joke
on
tact
bit
is
not
as
developed.
It's
that's
still
going
to
take
some
months,
at
least
to
finish.
I,
don't
know
what
the
deadline
is
this,
whether
that's
an
issue
a
lot?
U
C
D
Q
That
is
not
a
very
compelling
argument
in
a
community
with
many
many
activities
who
have
yet
to
make
an
investment,
but
nonetheless,
there's
a
tussle
going
on
here
between
people
who
have
made
an
investment
to
a
structural
form
and
people
who
are
considering
an
investment
and
it's
difficult,
I
acknowledge
it's
difficult.
So
the
particular
thing
that
I
brought
up
at
the
rrow
was
that
we
have
a
compellingly,
strong
desire
for
multilingual
representation
of
high
volumes
of
the
contact
information.
Q
We
have
a
specific
and
meaningful
use
case
that
relates
to
the
le.a
and
abuse
contact
function,
and
this
is
not
over
field
should
be
utf-8
so
that
it
can
be
a
name
in
Swedish
with
diacriticals.
It
is
we
they're
to
be
the
version
of
the
field
in
English
and
the
version
of
the
field
in
Croatian,
and
we
want
that
because
it
empowers
law
enforcement.
Behavior.
That's
based
on
this
thing,
called
mutual
or
assistance
program,
em
lab,
which
is
about
not
having
the
FBI
tried
black
helicopter
in
country
to
deal
with
criminal.
Q
It's
about
having
the
FBI
pick
up
the
phone
and
speak
to
a
policeman
in
Mongolia,
saying
by
this
bad
actor.
Can
you
speak
to
them
and
dual
language
representation
empowers
the
two
actors
to
talk
sensibly
about
the
data,
because
it
respects
the
hint
htdp
of
browser
preference
for
language.
Clearly
we're
not
going
to
have
that
we
do
69
languages
per
record,
you're
going
to
have
local
language
and
English
the
lingua
franca,
and
it's
going
to
that
is
quite
funny.
Isn't
it
and
it's
going
to
empower
a
circumstance?
Q
So,
whilst
I
am
here
saying,
please
can
we
consider
a
profile?
Please
can
I
ask
you
to
consider
investment
in
analyzing
is
a
profile
viable
and
I.
Understand
I'm
asking
you
to
we're
cost
and
faced
with
the
decision,
do
I
just
say:
Jas
contact
and
we're
out
of
here
or
do
I
invest
in
the
assessment.
I
am
asking
you
to
wear
a
cost.
I
would
like
you
to
do
that.
My
stop
line
in
this
is.
Can
you
confirm
that
you
can
support
a
dual
language
structure
that
is
not
the
same
as
multilingual
in
the
field?
Q
U
I'm
happy
to
anyone
about
this
after
this
is
new
again,
but
they
leave
leave.
Yes,
you
look
at
gets
calendar
of
this
similar
kind
of
spec.
It
has
an
approach
where
you
can.
Essentially
you
have
a
core
language
for
the
object,
but
you
can
so
pash
per
language,
so
you
can
say
each
of
these
things
now
in
this
language.
It's
these
sorry.
A
N
Next
slide,
this
is
the
graph
about
the
registration
report
definitions.
The
problem
we
try
to
address
is
actually
we
did
between
registries
and
registrar's.
We
do
not
share
common
formats
to
inform
what
specific
paper
reports
cook
should
contain
can
contain
trim
and
also
component
that
we
have
multiple
mechanisms
of
delivering
a
file.
The
report
right
now
ago.
We
can
actually
using
the
same
mechanisms
to
delivery,
not
all
of
the
reports,
but
the
reports
definition
file
as
well.
So
next
slide.
N
So
the
proposed
is
using
JSON
format
and
reach
the
reasons
behind
composing
JSON
is
because
reason
formation
is
simple:
it's
flexible
is
extendable
I,
and
the
current
mechanisms
for
report
deliver
is
rest,
HTTP
and
SFTP,
and
JSON
works
well
for
both.
If,
in
future,
there's
a
desire
for
EPP
a
song
can
can
converge
through
exam,
we
offer
a
fairly
straightforward,
but
conversion
to
XML
is
not
in
scope
for
this
draft
next
slide.
N
N
So
this
one
may
be
hard
to
repeat
this:
one
is
I
is
also
included
in
the
draft.
This
is
just
in
expanded
examples
with
what
could
be
contained
in
the
report.
Definitions.
This
example
here
contains
more
about
steam,
the
report
naming
format
and
about
steam.
The
report
definition
for
stuff,
like
versions
and
last
time.
This
definition
files
can
update
next
fly,
and
this
is
the
snippet
of
examples
about
the
the
few
definitions
is
this
example.
Here
it
talks
about
the
name
of
the
few.
N
A
Thank
you.
One
thing
that
is
important
to
point
out
is:
we
do
already
have
and
in
our
backlog
a
document
data
data
set
file
format
document,
so
this
is,
is
an
alternate
along
with
that.
So
at
some
point,
when
we
come
to
moving
to
this
work
item,
if
we
decide
we're
going
to
do
it,
then
obviously
we
would
bring
both
of
these
documents
up
together
so
that
we
could
go
through
them
as
a
working
group
and
see
what
we
wanted
to
do,
and
but
Jim
go
ahead.
G
A
Okay,
then,
thank
you
very
much
everyone.
We
do
have
one
last
item
on
our
agenda,
which
is
any
other
business,
but
let
me
just
you
know,
call
for
that
here
and
otherwise
we
are
a
couple
of
minutes
over
so
I
would
say.
The
right
thing
to
do
here
is
probably
just
say
that
we
are
done
I,
don't
see
anyone
jumping
to
the
mic,
no
one's
in
the
queue
over
here,
Thank,
You,
Joseph
and
so
we're
adjourned.
Folks,
thank
you
very
much.
Look
for
the
mailing
list.