►
From YouTube: IETF109-REGEXT-20201118-0500
Description
REGEXT meeting session at IETF109
2020/11/18 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
C
C
C
C
C
And
I
think
that
since
we
are
doing
that
early
on
in
the
process,
it
works
very
well
and
so
a
thank
you
to
everybody
who
volunteers
to
be
a
document
shepherds
and,
of
course
the
chairs
will
always
guide
people
that
want
to
become
a
document.
Shepard.
So
don't
worry
if
you
don't
understand
anything
about
the
procedures
yet
next
slide,
please
jim.
C
C
C
E
C
E
C
C
Wanted
to
have
a
discussion
with
the
document
authors,
which
is
gustavo.
This
is
the
last
time
we
will
put
this
on
the
agenda.
It's
of
our
milestone
list.
I
think
everything
that
the
working
group
needed
to
do
here
in
helping
with
this
document
has
been
done
so
if
there,
if
anybody
still
has
any
questions,
we're
happy
to
help
in
this
working
group,
but
we're
not
going
to
put
it
on
our
milestones
anymore,
but
the
the
the
regex
working
group
is
concerned.
The
word
for
this
document
has
been
done.
E
C
C
Barry
then
there's
7482
bis
and
7483
bis.
These
two
are
actually
waiting
for
me.
The
document
shoppers
have
done
their
write-up
with
the
help
of
us
and
we're
very
grateful
about
that.
And
basically
this
is
just
a
action
waiting
for
me,
but
in
the
week
before
the
itf
I
had
little
time
to
do
the
submission
and
probably
the
80s
are
busy
during
the
itf
week
as
well.
So
this
will
be
submitted
this
week
or
at
least
at
the
beginning
of
the
next
week.
C
No
and
then
we
have
two
documents
that
are
waiting
for
the
shepherd
write-ups,
which
is
the
secured
info
transfer
and
the
epp
unhandled
namespaces
waiting
for
the
shepherds
to
do
their
write-ups
one
comment
and
or
one
question.
I
have
to
ask
about
these
last
four
documents.
Actually,
because
for
three
of
these
documents
we
had
to
extend
the
working
group
last
call
now.
The
question
that
I
have
is
is
our:
we
are
a
small
working
group.
C
F
Yeah,
I
I
just
think
it's
natural,
I
think,
for
a
couple
of
these,
they
were
just
late,
detailed
feedback
that
came
back
from
the
working
group
that
needed
to
be
worked
out.
So
I
don't
think
that
they
need
to
be
extended
from
two
weeks
to
three
weeks
or
some
longer
period
of
time,
but
I
also
wanted
to
point
out
one
additional
item
on
the
unhandled
name.
C
You
jim
well
you
and,
as
a
remark
back,
you
know,
it
could
also
be
that
we
are
calling
out.
The
working
group
last
call
too
early
right
when
there
has
not
been
enough
review
being
done
during
the
normal
working
group
time
that
we
have
for
the
documents,
and
it
could
also
be
that
that's
why
we
get
a
lot
of
remarks
that
still
have
to
be
implemented
in
the
document
during
the
working
group.
Last
call.
D
B
Okay,
thanks
antoine-
and
this
is
the
the
last
comment
and
discussion
is
kind
of
a
nice
segue
into
this
particular
document.
It
unfortunately
found
itself
in
a
in
a
place
where
we
had
some
interesting
discussion
during
the
working
group.
Last
call
that
again,
we've
said
a
few
times.
We
know
we're
a
small
group,
and
you
know
when
you
end
up
with
just
two
people
who
are
having
a
discussion.
We
really
wanted
to
try
and
get
some
additional
input
and
we
guess
we
didn't
spark
enough
interest.
B
B
B
B
F
Please
about
about
doing
late
feedback.
I
apologize
the
working
group
when
the
working
group
last
call
came
up.
I
decided
to
do
a
deep
dive
on
this
particular
draft.
So
that's
the
result
of
the
deep
dive
but
yeah.
I
encourage
others
in
the
working
group
to
also
do
that
kind
of
deep
dive
earlier
in
the
process,
if
possible,.
B
G
Thanks,
can
you
hear
me?
Okay,
yes,
very
good.
Rick
wilhelm
heard
the
record
on
this
particular
one.
I
also
have
had
a
some
separate
conversations
with
some
folks
on
the
that,
I
would
say,
are
approaching
this
a
little
bit
more
from
the
business
side,
not
just
the
technical
side
and
I'm
gonna
be
gonna.
I'm
not
I'll.
Either.
Do
this
on
my
own
or
with
with
gould
but
but
put
in
some
comments
here.
G
I
think
that
we'll
need
to
discuss
if
it
does
that,
just
due
to
the
way
that
the
the
maintenance
notification
process
would
work
via
the
pull
queue,
because
if
a
registry
is
notifying
another
party
by
the
poll
queue
it's
it's
unclear
exactly
when
that
is
going
to,
if
that's
going,
to
satisfy
the
the
business
requirement.
Also,
so
I
think
that's
something
that
we'll
need
to
I'll
try
and
work
to
bring
that
up
in
a
comment.
I
just
want
to
state
it
here
to
give
a
little
bit
of
a
preview.
B
Thanks
for
that
rick
I'll
channel
antoine
a
little
bit
here
and
just
you
know,
make
a
comment
for
us
antoine,
and
I
often
have
this
discussion
about
you
know
I
I
can
requirements
or
not.
I
can
requirements.
We
do
need
to
be
a
little
careful
just
to
keep
separate
any
policy
considerations
from
technical
considerations.
B
That
kind
of
thing
I
mean
I
do
appreciate
what
you're
what
you're
after
here
you
know,
poll
messages
are
handed
very
differently,
typically
asynchronously
from
the
synchronous
communication
that
our
policies
typically
require,
but
we
should
certainly
examine
whether
or
not
that's
an
issue
for
this.
This
specification
or
not.
B
The
rdap
reverse
search
capabilities.
Searches
is
certainly
important
stuff
in
rdap
for
a
variety
of
reasons,
and
this
work
has
been
languishing
for
a
long
time
but
mario,
I
believe,
you're
ready
to
step
up
and
help
us
try
to
invigorate
this
work
a
bit.
Would
you
like
me
to
put
up
your
slides
for
you,
or
did
you
want
to
present
marielle.
H
H
H
The
the
the
goal
of
these
two
proposals
is
to
is
to
provide
authorities
with
fast
access
and
authenticated
access
to
registered
data
through
obviously
registered
data
discovery
services.
So
I
think
that
this
proposal
goes
in
the
same
direction
of
the
goal
of
the
reverse
search
draft.
So
I
think
that
rivet
sasha
is
furtherly
justified
by
the
the
the
evolution
and
the
progress
of
this
proposal,
at
least
within
the
european
union
countries.
B
B
B
You
know,
on
the
icann
side,
there's
a
lot
of
work
going
on
on
the
icann
side,
with
respect
to
whether
or
not
search
should
be
present
or
not,
and
what
that
means
so
it'd
be
very
good
to
have
a
technical
understanding
of
what's
possible
so
that
we
can
continue
that
discussion
on
that
side
and
with
that
scotch
have
your
hand
up
go
ahead.
Please.
B
Thank
you,
scott
and,
of
course,
as
you
know,
you
know,
documents
nowadays
have
a
spot
and
we
talked
about
this
before
in
the
in
this
working
group.
Although
we
never
came
to
any
conclusion
about
it,
but
there
is
an
opportunity
for
a
privacy
consideration
section
in
a
document
and
and
that
would
be
something
that
you
know.
We
should
just
consider
how
to
fill
that
out
in
this
document.
B
J
Thank
you,
mario.
The
the
one
point
I
want
to
spell
out
is
we're
currently
working
on
implementing
an
rdap
prototype
4.80,
and
what
I'm
using
now
is
plain
chain
word
tokens.
So
it's
not
full
blown
open
id,
but
I
certainly
know
that
we
need
some
kind
of
scalable
authorization
infrastructure.
If
we
give
that
to
third
parties,
let
me
put
it
that
way
very
carefully.
L
There
you
go
yeah,
I
just
want.
This
is
oldish
from
this
british
registry.
I
wanted
to
say
that
mario
has
actually
done
the
privacy
consideration
part
and
because
we
have
had
this
discussion
here
in
the
group
quite
often,
and
I
think
so
the
document
has
improved
from
that
part.
I
would
actually
ask
how
do
we
know
that
this
is
a
good
privacy
consideration.
L
B
So,
thank
you
for
that
question
ulric.
I
wonder
if
maybe
we
can
put
our
ad
on
the
spot
here
and
ask
I
I
have
to
say
that
I
don't
think
that
I've
seen
any
significant
privacy
consideration
section
at
least
myself
in
in
having
looked
through
documents.
Nothing
that's
crossed
my
desk.
If
you
will
have.
B
C
Now
their
work
was
mostly
about
trying
to
get
this
document
not
not
published
because
they
didn't
like
the
idea
at
all
where
we
asked
them
that
they
could
help
write
a
sufficient
privacy
considerations
section.
So
we
I
think
I
guess
we
can
ask
them
again
to
review
the
privacy
considerations
section.
While
you
know
the
what
the
document
for
the
rest
describes
is
actually
how
to
do
reverse
search
and
not
when
to
do
research
search.
E
And
just
that
comment
on
privacy
considerations
sections
so
there
wasn't.
There
was
an
iab
document
some
years
ago
that
discussed
privacy
issues
and
recommended
that,
if
that
that
you
might
include
a
privately
considerate
infection,
if
there
were
significant
privacy
issues
that
needed
to
be
covered,
there's
no
requirement
to
have
a
privacy
consideration
section
and
most
documents,
as
jim
noted
don't.
E
B
B
J
So
I
think
that
that
we
should
point
out
that
there
are
significant
privacy
implications
on
providing
research.
Reverse
search.
Yes,
but
but
I
believe
that
there
is
no
need
to
say
in
a
technical
document,
not
follow
the
law,
because
that's
quite
obvious
and
and
what
we
could
say
is
maybe
that
yeah
this
is.
This
is
obviously
highly
privacy.
Relevant
and
implementers
must
yeah,
but
must
consider
legal
implications
yeah
as
easy
as
that,
and
then
must
follow
the
local
law.
J
I
I
mean.
I
do
believe
that
we
can't.
We
can't
fix
any
problems
that
the
lawmakers
have
have
introduced
in
those
directions,
but
it
would
be
at
the
minimum
as
engineers
we
should
say
that
hey
we
got
concerns
here.
This
is
a
sensitive
topic.
You
must
address
this
before
you
actually
put
out
your
registration
data
on
the
internet.
B
B
The
privacy
considerations
section
should
at
least
say
something
about
the
questions
that
are
being
raised
by
the
human
rights
folks,
and
that
might
be
the
best
that
we
can
do
and-
and
you
know
that's
that's
the
path
that
we
should
look
for
and,
of
course
make
sure
that
we
are
completing
anything
that
might
be
in
the
iab
document.
So,
okay,
ulrich
you're,
going
to
get
the
last
word
here,
go
ahead.
Please,
okay,.
B
So,
thank
you
for
that
ulric
I
like
that.
It
would
probably
be
especially
helpful
if
you
would.
You
know,
take
a
look
at
the
document
and
what's
there
and
and
bring
that
comment
and
that
question
to
bear
on
your
review
of
the
document
and
and
say
something
on
the
mailing
list
about
that.
That
would
be
very
helpful
to
us.
I
agree
with
you
so,
okay
with
that,
I
think
we're
a
little
bit
behind
schedule
here,
not
a
lot.
We
do
have
a
few
minutes
at
the
end,
so
we're
okay.
B
M
Awesome,
I
still
remember
my
last
last
time:
okay,
thanks
everyone.
This
is
the
simple
registration
reporting.
This
is
about
the
the
standardized
set
of
report
that
registry
can
provide
for
registrar
so
that
we
we
have
a
consistent
expectations
of
what
being
produced
and
and
how
registered
consume
next
slide,
not
well,
no,
not
well
thanks.
M
M
M
F
F
So
if
you
wanted
to
find
in
a
registry
around
the
fields
and
the
reports
in
the
process
for
updating
diana
registry-
that's
that's
fine,
so
that'd
be
focused
on
the
framework,
but
the
specific
reports,
I
think,
will
be
very
difficult
to
get
consensus
on
and
that
gets.
My
second
feedback
on
them
is
the
track
of
this
draft
because,
right
now
I
guess
it's
defined
as
informational.
F
M
B
B
Quick
comment,
as
as
a
co-author
here
with
joseph-
I
think
that,
structurally,
if
you
want
to
put
this
into
two
documents
where
the
framework
is
won
and
and
the
initial
document
specification,
if
the
issue
report
specification
is
a
separate
document,
you
know,
I
think
that
would
that
seems
fine
to
me.
If
anybody
has
any
objections
to
that,
be
good
to
to
hear
that
that'd
be
something
to
think
about.
I
think
that's
a
one
response
to
jim
gould's
thing
more
directly
to
the
question
of
the
status
of
this
document.
B
Actually
that
would
be
a
question
at
the
end
of
this.
This
thing
you
know
I
I
do
actually.
I
agree
with
you,
jim
gool.
You
didn't
actually
say
this,
but
speaking
for
myself,
I
was
actually
thinking
this
document
should
go
to
standards
track.
Certainly
the
framework
should
be
standards
track.
The
actual
reports-
maybe
not
so
maybe
that's
another
reason
for
splitting
the
document.
B
I
think
that
it
was
just
an
artifact
of
how
we
started
that
we
made
it
informational
to
start
with,
but
I
think
a
fair
question
at
the
end
of
this
presentation,
for
the
working
group
to
think
about
is
confirming
that
it
would
be
good
to
move
this
to
standard
track,
at
least
the
framework.
So
that's
an
open
question
interested
in
hearing
from
folks
with
that,
alex
have
your
hand
up
go
ahead,
please
thank
you.
Jim.
J
There
was
one
question
to
draft
about
the
empty
values.
I
think
that
that's
the
problem
of
the
of
the
output
format
for
quite
concretely,
first
years,
we
I
would
like
to
see
empty
columns
yeah
for
other
formats,
that
we
might
be
waiting
in
the
future,
like
whatever
there
are
formats
for
that
in
in
the
in
the
data
format
itself.
On
the
second
part,
I
agree
with
what
what
you
jim's
have
said.
J
And
then
we
we
are
pretty
free
to
define
whatever
reports.
We
have
an
informational
document,
or
maybe,
if
we,
I
don't
know
what
the
registry
policy
is
at
the
moment,
if
it
is
just
specification
required,
then
other
folks,
like
I
can
work
in
groups,
can
can
pretty
much
define
their
own
reports
and
register
them
with
cyano
without
the
need
to
go
through
and
through
the
rsc
process,
if
it's
just
specification
required.
So
I
think
that
that
would
be
a
valuable
extension
of
that.
M
M
F
F
B
So
I'll
offer
a
quick
response
to
that.
The
the
the
current
way
this
thing
is
defined
is
a
first
come
first
serve
registry
with
specification
required,
so
it
doesn't
have
to
be
an
internet
draft
or
rfc,
but
there
does
have
to
exist
a
specification
for
the
report
and
for
any
data
elements
that
might
be
defined.
Also,
that's
similar
to
the
way
the
epp,
extensions
and
rdap
extensions
registry
was
done.
B
M
M
It
will
ask
to
develop
a
small
pool
of
individuals
to
serve
as
the
designated
expert
that
mirrors
what
we
have
for
the
epp
extensions
right
now
we
will
we
propose
to
use
the
current
rejects
mailing
list
for
the
public's
discussion
for
any
request.
So
that
means
the
rejects
mainly
will
be
asked
to
continue
to
to
be
open
and
remain
negative.
O
C
D
C
B
D
B
M
M
M
There's
some
topics
related
to
this
draft.
We
have
not
been
captured
and-
and
that
will
be
open
for
discussions,
especially
about
what
should
be
the
name
for
the
report
and
what
elements
should
be
part
of
it.
If
the
file
is
too
large
when
we
do
the
splitting
or
if
we
do
any
compressions
next
slide,.
B
So
one
of
the
things
we
want
to
leave
the
group
with
here
is
the
question
of
status
of
the
framework
certainly
heard
a
discussion
to
split
this
document.
So
that's
a
good
thing,
there's
also
a
question
of
a
milestone
date
which
we're
going
to
get
to
in
just
a
moment,
but
we
have
a
question
about
that
too.
For
this
document,
jim
gold,
you
have
a
hand
up
ahead.
B
F
B
So
the
idea
being
that
you
would
only
define
elements
that
exist
in
in
reports
that
are
being
used.
You
know
we
could
certainly
choose
a
different
path
which
you're
suggesting
we
could
do
that.
If
folks
think
that
that's
more
helpful-
and
in
that
case
we
might
even
just
go
back
to
the
data
mapping
document
that
was
mentioned
earlier
and
refer
to
that,
but
anyway
go
ahead.
You
want
to
respond
to
that.
B
M
B
Yeah
and
gavin
brown
in
the
chat
room
just
to
call
out
for
the
record
here,
is
also
pointing
out
that
there
was
an
inventory
of
registration
data
elements
that
fed
into
the
development
of
rdap
itself.
So
we
do
have
a
couple
of
choices
here.
If
we
want
to
expand
the
list
of
potential
data
elements
just
to
have
a
baseline
for
for
use
by
by
all
reports,
we
could
certainly
explore
that,
if
that's,
what
folks
think
would
be
more
helpful
in
in
this
document,
you
know
we
can
certainly
do
that.
B
So
we'll
take
that
discussion
to
the
mailing
list
here
and
see
what
folks
want
to
do
putting
on
a
chair
hat
here.
I
think
it's
important
to
draw
a
line
under
this
discussion
at
this
point
and
move
on
we're
kind
of
running
out
of
time
here.
So
let
me
get
back
and
say.
Thank
you,
joseph.
Let's
get
back
to
our
chair,
slides
here,
so
we
can
see
where
we
are
and
move
to.
The
next
thing
here,
which
I
believe
is
a
discussion
of.
B
Oh
now,
we're
gonna
have
a
little
presentation
about
some
new
work
before
we
talk
about
milestones,
so
we
have
a
number
of
items
that
are
in
front
of
us
and
available
to
us
to
think
about
for
new
work,
and
we
have
some
presentations
that
go
with
some
of
these,
but
not
all
of
them.
In
fact,
the
first
one
up
here
is
the
unrenewable
extension
from
from
jody,
and
so
we
have
some
time
allotted
here
for
discussion
about
these
things.
P
Absolutely
can
you
hear
me
all
right,
jim?
Yes,
please
go
ahead,
all
right,
I'm
sorry!
I
don't
have
any
slides
for
this
and
and
I'll
try
to
get
through
this
as
quickly
as
possible.
I
know
I
have
20
minutes
but
we're
running
a
little
bit
behind
quack
fam
and
from
godaddy
registry,
and
I
have
been
working
on
a
way
to
do
to
undo
an
explicit
renewal.
P
Without
deleting
the
domain,
we
will
have
a
paper
coming
out
or
submitting
a
paper
that
we
hope
can
be
adopted,
I'll
just
go
through
the
history
of
it
first
and
and
the
issues
that
we
see
in
order
to
receive
a
refund
for
a
registration
of
a
domain.
The
domain
must
be
deleted
within
the
registration
grace
period.
P
Now
this
seems
to
make
sense,
because
the
customer
may
misspell
the
domain
name,
and
then
they
only
have
five
days
after
the
domain's
been
created
to
delete
the
domain,
there's
not
much
to
be
gained
by
the
registrant
in
gaming,
the
system
and
and
it's
a
and
it
seems
to
make
sense,
it's
pretty
logical
in
order
to
receive
a
refund
for
a
domain
that
has
been
auto
being
renewed
by
the
registry.
The
registrant
needs
to
delete
the
domain
again.
P
D
P
Main
auto
renews
at
the
end
of
that,
so
the
customer
has
actually
paid,
for
you
know
a
complete
year.
The
domain
name
renews
at
the
end
of
that
year
or
auto
renews
at
the
end
of
the
year,
and
then
the
customer
has
45
days
and
in
order
to
get
money
back
for
that
auto
renewal,
the
the
registrant
needs
to
delete
the
domain
name,
the
registrant
and
the
registrar.
P
P
Now,
there's
various
reasons
how
this
could
happen.
You
know
one
of
them.
I
think
that
we've
all
probably
experienced,
as
is
bad,
a
bad
internet
connection
if
you've
ever
getting
or
ever
gotten
to
a
cart
and
you
put
in
your
your
credit
card,
you've
hit
the
submit
button
and
all
of
a
sudden
it
hangs,
the
website
hangs
you
lose
your
connection,
etc,
and
then
we're
not
sure
if
that,
whatever
you've
purchased
has
has
been
completed.
P
This
can
happen
to
registrants
and
what
will
happen
is
they'll
immediately
freak
out
about
it
and
and
they'll
come
in
and
they'll
try
to
purchase
it
again
in.
In
some
cases
the
renewal
could
have
actually
have
gone
through
have
gotten
to
the
registrar.
The
registrar's
already
submitted
the
renewal
to
the
registry,
but
unbeknownst
to
the
customer.
They
come
in
and
get
nervous
and
renew
it
again.
P
This
can
happen
multiple
times
in
in
order
to
to
get
back
the
money
that
they've
had.
If
they've
only
wanted
one
renewal
and
they
wound
up,
sending
six
renewals
or
or
a
five
year,
renewal,
etc,
they
would
have
to
delete
that
domain
name
in
order
to
get
it
back,
they're,
not
willing
to
delete
the
domain
name
and
forego
the
rest
of
their
registration
life
cycle.
On
that
we've
had
this
happen
many
times,
another
issue
could
be
with
interfaces.
P
Customers
could
could
renew
the
domain
name
for
10
years
when
they
really
only
wanted
to
renew
it
for
one
year.
Another
issue
is
as
much
as
I'd
like
to
believe
that
developers
are
perfect.
They
are
not,
and
you
know,
developers
may
institute
something.
That's
that's
renewing
domain
names
for
the
incorrect
number
of
years
and
and
there's
no
way
to
back
that
out
now.
P
As
far
as
the
first
issue
goes
as
a
registrar,
we've
had
many
calls
with
customers
trying
to
explain
to
them
that
we're
sorry,
but
in
order
to
get
your
renewal
the
renewal
funds
back,
they
would
have
to
delete
the
domain
name.
This
has
led
to
a
lot
of
extreme
customer
dissatisfaction
and
in
some
cases
we've
had
to
just
refund
the
registration
or
the
renewals
to
the
to
the
customer
in
order
to
keep
a
happy
customer,
but
we
would
eat
the
cost
of
the
renewals
at
the
registry.
P
The
way,
the
way
that
we
would
see
an
unrenewed
command
would
work
is
that
what
we've
discussed
is
adding
an
unrenew
extension
to
the
renewal
command.
The
unrenew
would
be
time
bound.
It
could
only
be
done
within
the
renewal
grace
period,
and
so
it
would
usually
that's
five
days,
but
I
know
different
cctlds
have
different
different
restrictions
for
that.
P
A
successful
domain
renewal,
press
unrenewable
request
will
result
in
the
renewal
charge
being
refunded,
but
the
unrenewed
does
not
apply
to
auto
renewals
registers
are
provided
45
days
and
auto
renewable
grace
period
to
delete
the
domain
name
and
the
domain
is
at
the
end
of
the
lifecycle,
like
I've
said,
and
it
shouldn't
bother
the
customer
to
delete
that
domain
name.
At
that
time
we
would
see
the
actual
unrenew
working
as
a
queue.
P
P
P
What
we
found
in
discussions
is
that
it
helps
the
accounting
department
to
be
able
to
line
up.
You
know
an
unrenewed
command
with
a
renew
command
to
determine
when,
when,
when
costs
have
been
backed
out,
there
are
other
things
to
consider.
Here,
too,
is
like
you
know:
how
could
how
could
a
renewed
command
an
unrenewed
command
be
gamed?
How
could
an
unrenewed
command
should,
should
it
unrind
the
renewals
that
set
the
expiration
date
in
the
past?
P
P
That
that's
a
good
question.
You
know
a
registry
could
implement
an
unrenew
by
allowing
a
customer
or
a
registrar,
to
call
in
and
say,
hey
I'd
like
to
unrenew
three
of
these
10-year
domain.
Renewals
that
I
just
sent
in
in
epp
command
is
something
that
we
that
we
would
see
to
be
an
advantage,
because
we
see
thousands
of
these
a
month.
I
mean
it
is.
It
is
quite
it
it's
a
very
big
problem
for
us
and
in
sending
a
thousand
emails
to
the
registry
to
unrenew
those
domains.
D
Thank
you,
jim
yeah,
so
thank
you
jody
for
for
for
talking
about
this.
This
idea,
I
had
a
few
things
I
wanted
to
to
just
bring
to
the
attention
of
everyone
on
this
on
in
their
meeting.
First
one
is
that
there
is
actually
prior
art
for
this.
The
I
believe
the
nominee
registry
system
has
an
unrenew
command.
I
don't
know
I
did.
I
think
it
was
a
pre-epp,
but
it
I'm
pretty
sure
that
that
existed,
so
there
is
at
least
one
registry
of
reasonable
scale
that
is
offering
this
service.
D
P
B
J
J
P
Really,
I
think,
thanks
for
your
question
alex,
we
had
discussed
that
and
being
able
to
say
if
you
renew
the
domain
name
for
ten
years
and
then
sending
it
on
renew
for
like
three
years
of
those
ten
years,
so
that
you
would
have
a
seven-year
renewal.
We
decided,
as
you
said,
that
that
just
got
too
complicated
on
the
registry
side
to
implement,
and
it
did
lead
to
some
business
logic
and
some
accounting
principles
that
we
weren't
comfortable
with.
P
P
So,
as
I
said,
if,
if
a
customer
came
in-
and
let's
just
say,
they
did
a
one-year
renewal
followed
by
a
two-year
renewal,
followed
by
a
three-year
renewal.
For
some
reason,
the
first
unrenewed
command
would
undo
the
three-year
renewal.
The
second
unrenewed
command
would
un
do
the
the
two-year
renewal
and
then
the
third
one
would
undo
the
one-year
renewal
just
to
keep
everything
in
a
queue,
and
then
it
would
just
undo
the
previous
actual
renewal,
regardless
of
how
many
years
it
was.
J
Yes,
indeed
it
does,
I
mean
unrolling.
The
queue
itself
is
is,
is
not
a
another
fun
problem
to
address
itself,
so
I
my
reference
would
be
that
only
the
last
renew
command
could
be
reversed,
but
but
well
I
see
my
developer
cringe
as
soon
as
I
say.
Well,
you
have
to
keep
a
queue
of
renewal
commands
that.
G
Good,
thank
you,
jim
rick
wilhelm,
so
one
I.
I
agree
with
the
previous
comment
that
you
made
jody
about
not
doing
a
partial
on
renew
that,
from
a
from
a
business
and
accounting
and
reporting
standpoint.
That
sounds
like
a
real
headache,
so
plus
one
of
that
overall,
this,
the
unrenews,
is
very
interesting
and
I
think
I
think,
has
a
lot
of
potential
to
be
very
useful.
G
The
the
challenge,
though,
that
I
see
in
this
is
that
this
is
really
heavily
dependent
on
the
business
rules
and
something
to
which
jim
reed
alluded
brought
up
in
chat
and
alex
also
kind
of
brought
up,
and
I
think
and
the
the
issue
there
is
that
at
least
for
most
for
gtld
registries,
which
are
a
large
part
of
the
the
use
use
case
for
this.
This
is
going
to
have
to
go
through
a
fair
bit
of
icann
policy
related
work.
G
This
does
operate
in
a
pretty
in
inside
of
a
context,
and
that
context
is
a
lot
of
has
a
lot
of
business
rules
and
not
the
least
of
which,
and
some
of
the
complicated
ones
around
here
relate
to
reporting
requirements
and
also
there's
fees
that
gets
charged,
and
things
like
that.
So
I
think
that
that's
something
that
if
draft
does
go
forward,
we'll
have
to
take
into
account
and
then
for
it
to
actually
take
root
in
the
gtld
speech.
They
have
to
be
icann
policy
work,
I
believe,
done.
P
Thanks
rick,
I
was
trying
to
keep
the
four
letter
acronym
out
of
here,
but,
but
I
I
I
agree,
we
had
we
had
discussed
whether
an
arser
would
have
to
be
or
an
rsep
would
have
to
be
done
for
this,
and
and
yes,
I
I'm
not
blind
to
the
fact
that
this
could
cause
a
lot
of
issues
with
icann
and
and
how
how
it
could
be
implemented.
But
I
appreciate
the
feedback
thanks.
B
Okay,
thank
you
jody.
We
look
forward
to
moving
on
with
this,
so
we'll
move
on
to
the
next
item
in
our
our
new
work
here,
the
js
contact
in
in
rdap.
This
is
something
we
actually.
I
don't
know
if
we
had
the
discussion
here
in
this
group
before,
but
it
certainly
has
been
presented
in
other
registration
fora,
but
over
to
you,
gavin
go
ahead.
Please.
D
D
Obviously,
the
reason
why
mario
and
I
are
bringing
this
to
to
the
regex
group,
this
itf
meeting
is
because
we
we're
asking
for
it
to
be
considered
for
adoption
by
the
working
group.
So
I'm
just
gonna
give
a
precede
of
of
the
heart
of
this
this
this
draft
at
a
high
level,
so
that
that
that
consideration
can
take
place.
D
Essentially
because
it's
almost
to
the
point
of
it's,
it's
a
it's
a
machine
interpretation
or
rather
than
a
human,
readable
representation.
Mario
has
done
some
research.
I
I
wasn't
able
to
provide
a
reference
to
this,
but
I'm
sure
mario
will
be
able
to
that
something.
At
least
half
more
than
half
of
all
of
the
rdap
records
for
the
nic
zones.
D
In
the
gtld
space
contain
at
least
one
j-card
error,
so
even
even
you
know,
as
I'd
say,
a
majority
of
tld
operators
are
unable
to
correctly
construct
a
j-card
object,
and
that
clearly
means
that
there
are.
There
are
serious
challenges
in
interoperability
in
maintain
maintainability
and
just
in
the
the
doing
the
work
of
implementing
jcard
in
odd
app
servers
and
so
looking
at
alternative
options.
One
that
that
comes
to
mind
is
just
contact
which
provides
a
simpler
and
more
efficient
representation
of
of
contact
information.
D
So
next
slide.
Please
js
contact
is
a
draft,
that's
being
developed
separately
from
from
this
draft,
and
it's
part
of
an
overall
effort
to
try
and
standardize
restful
interaction
with
productivity
systems
like
email,
calendaring
and
address
books
and
we're
making
use
of
that
work
to
make
it
available
to
rdap
implementations.
D
It's
a
json
native
representation
of
contact
data.
It
doesn't
doesn't
kind
of
it's,
not
a
compilation.
Artifact
in
the
way
that
js
card
is
j
card
is
sorry,
I
get
confused
it's.
It
also
has
a
number
of
features
that
that
are
either
not
available
in
j
card
or
are
not
easily
implemented
in
j
card,
particularly
around
unstructured
contact
information
and
internationalized
contact
information,
and
particularly
on
the
internationalization
front.
There
are.
D
D
You
simply
remove
the
b
card
array
from
the
from
the
the
entity
object
and
replace
it
with
a
js
card
object,
so
very
very
little
in
the
way
of
substantial
changes
to
the
rdap
responses
themselves
other
than
one
one.
One
data
element
gets
swapped
out
for
another,
but
there
is
a
need
to
signal
to
a
client
that
a
server
does
support
js
card
and
also
a
way
to
gracefully
transition
from
from
the
current
state
to
the
future
state,
so
that
so
the
document
describes
a
transition
process
with
four
phases.
D
D
D
D
So
just
a
little
bit
of
metadata
about
the
the
draft
itself,
we
published
the
first
version
in
march
this
year.
The
there
have
been
three
three
subsequent
reverse
revisions.
There
is
some
work
still
to
do,
but
we
we
kind
of
feel
that
the
best
place
for
that
work
to
take
place
is
within
the
working
group
now,
because
we
really
want
to
bring
in
as
many
stakeholders
as
possible
to
to
try
and
get
to
get
some
eyeballs
onto
onto
this
to
to
hammer
out
the
educations
and
the
complexities.
D
So
this
is
why
we're
advancing
it
for
consideration.
We
have
one
implementation
currently
available,
which
is
in
it.
They
have
that
in
their
in
their
test
bed
system
and
obviously
we
would
look
to
to
get
at
least
one
more
additional
implementation
and
and
some
client
implementations
as
well,
if
possible.
D
When
I
presented
this
at
the
row,
there
was
very
positive
feedback.
I
think
very
few
people
said
that
jay
card
was
was
was
fun
to
work
with,
and
I
think
that
that's
that
was
positive
and
encouraging,
and
I
think
we
need
to
harness
that
that
enthusiasm
for
an
alternative
as
quickly
as
possible
so
that
we
can
get
rid
of
j
card
and
everyone
can
get
on
with
their
deal
with
their
jobs.
B
Thanks
kevin
so
for
the
working
group,
this
is
the
all
of
this
new
work.
The
presentation
we're
listening
to
here
here
the
worker
is
gonna,
have
to
consider
if
it
wants
to
adopt
the
work.
That'll
be
a
question
we'll
take
to
the
mailing
list
and
also
interested
in
any
discussion
here
on
those
questions
alex
go
ahead.
Please.
B
B
E
K
Q
Q
6530-6533
they
are
in
this
or
that
stage
of
deployment.
Now
the
main
feature
of
this
set
of
standard
is
that
they
allow
non-ascii
left
part
of
the
email
addresses,
but
anyway,
a
lot
of
protocols
still
refer
to
the
old
syntaxes
of
email
addresses,
and
it
means
that
if
we
want
to
implement
the
yeah
addresses,
it
requires
explicit
protocol
changes.
For
example,
rfc
8399
introduced
such
changes
into
certification
in
the
x509
certification
profile.
Next
slide,
please.
Q
Q
Q
Q
Q
B
J
J
I
don't
see
any
reason
why
we
would
not
allow
eai
in
the
standard,
email
attributes
of
the
of
the
epp
contact
and
if,
if
a
server
does
not
support
it,
they
would
return
a
three
2
306
per
meter
policy
error
in
epp
explaining
that
it's
not
possible
and
that's
it.
So
I
quite
frankly,
maybe
I
missed
something,
but
I
don't
see
that
there
is
much
radio
edit
here
besides
like
pushing
at
another
epp
extension
on
top
of
the
registry
and
registrars
that
they
need
to
support.
Q
B
F
Q
I
Go
ahead,
scott
thanks,
jim
scott
holland
back
here-
and
I
know
I'm
probably
channeling-
alex
a
little
bit
here,
but
I
think
you
know
part
of
the
issue
here
is
not
really
about
the
xml.
It's
that
a
lot
of
implementations
have
another
layer
of
processing
that
is
problematic
like
a
regular
expression,
parser
or,
for
example.
You
know
that
that's
used
to
look
at
the
you
know
the
left
side
of
an
email
address
and
make
sure
that
it
conforms
to
the
syntax.
I
You
know
specified
in
the
current
normative
references
and-
and
so
I
think
we
do
need
some
kind
of
a
signaling
mechanism.
You
know
between
the
client
and
the
server
to
indicate
support
for
something
that
would
do
something
different
in
terms
of
validating
the
local
part.
So
I'm
definitely
not
a
fan
of
you
know.
Going
back
and
trying
to
update
the
core
epp
rfcs,
for
example.
I
mean
this
is
the
whole
reason
we
have
an
extension
mechanism,
so
we
could
add
capabilities
like
this
without
updating
these
core
specs.
I
And
so,
if
we
decide
that
we
want
to
do
this,
I
I
definitely
prefer
the
idea
of
coming
up
with
an
extension
new
xml,
namespace
and
some
type
of
a
signaling
mechanism,
so
that
people-
and
you
know,
clients
and
servers-
know
that
you
need
to
do
something
different
here.
You
know
to
allow
non-ascii
characters
in
the
local
part
of
an
email.
I
B
Thanks
scott
I'll
just
speak
for
myself
and
comment
quickly
that
you
know
I
I
wonder
sometimes
why
people
have
make
any
business
of
checking
the
local
parts
should
be
allowed
to
be
whatever
whatever
the
user
wanted
it
to
be.
But
I
I
do
get
usability
concerns
we
like
to
help
the
user
make
sure
they
do
the
right
thing.
So,
john
kang,
you
have
your
hand
up
guide.
Please.
R
Hello,
can
you
hear
me?
Yes,
we
can
go
ahead.
Please,
okay,
so
because
ei
is
deploying
is
currently
in
deploying
many
email
service
providers
such
as
microsoft,
google
and
apple,
so
for
further
further
some
local
countries
in
china
and
india
and
other
countries
all
have
deployed
yeah
so
service.
So
some
country,
some
users
or.
R
D
F
Brought
up
about
the
the
fact
that
it's
not
an
xml
issue,
but
there
is
an
issue
on
the
server
side
and
the
fact
that
how
the
data
is
stored
because
the
domain
part
could
be
peanut
code,
but
the
local
part
could
be
utf-8
and
pretty
much
the
ability
for
the
server
support.
Storing
that
utf-8
is
important
from
a
signaling
perspective.
B
Thanks
dmitry,
I
think
the
question
for
the
working
group
is
based
on
this
discussion.
There's
some
question
as
to
whether
there
is
something
to
do
here
so
part
of
adopting
it
for
us
to
think
about
here
will
come
to
that
question
is:
do
we
do
we
believe
that
there's
work
to
be
done
here,
since
one
of
the
options
was
to
do
nothing,
so
we
do
need
to
think
about
whether
we
want
to
focus
on
the
signaling
mechanism,
and
then
we
can
talk
about
the
way
in
which
to
do
that.
B
A
A
So
for
us
we
delegate
large
blocks
to
national
registries,
and
then
they
make
delegations
out
of
those
blocks
to
their
own
account
holders.
Currently,
if
somebody
does
an
art,
app
query
they'll
get
information
back
about
those
smaller
delegations,
but
it
can
be
useful
to
know
about
the
delegation
that
we
made
to
the
national
registry
as
well.
A
D
A
A
The
third
use
case
is
when
the
redirector
and
the
target
have
differing
information
about
the
resource,
so
the
client
can
combine
the
two
responses
to
get
a
fuller
picture
of
what's
going
on
and
the
fourth
is
similar
to
the
second
one
in
that,
if
the
target
is
unavailable
and
the
client
is
willing
to
live
with
the
less
specific
information,
then
they
can
fall
back
onto
that
next
slide.
Please.
A
This
document
has
text
along
the
lines
of
a
server,
will
will
usually
or
ought
to
include
html
with
a
link
to
the
target
resource,
but
none
of
that
text
is
normative
and
there's
also
no
text.
That
says,
for
example,
don't
return
substantive
content
in
a
redirect,
so
it
appears
to
be
okay
as
against
this
document.
Next
slide,
please.
A
However,
there
is
well
in
a
way
this
isn't
really
returning
the
answer.
It's
returning
information,
that's
related
to
the
answer,
so
we
think
it's
distinguishable
from
the
current
text
in
the
document
and
there's
also
nothing
normative
here.
That
would
prevent
returning
this
body,
but
it
is
it's
an
arguable
issue
for
this.
One
next
slide:
please,
the
document
as
it
stands
doesn't
have
any
client
signaling.
A
If
a
server
supports
this,
then
it
always
returns
the
content
that
it
has.
If
it's
redirecting.
There
are
two
reasons
for
this.
The
first
one
is
that
when
you
have
a
chain
of
redirects,
there's
no
need
for
each
server
to
pass
on
the
signal,
and
the
second
is
that
without
signaling,
this
is
all
just
the
property
of
the
response
and
it
might
be
possible
to
skip
the
ietf
process
and
just
register
this
as
not
app
extension
next
slide.
A
That
document
had
in
mind
a
model
where
the
rdap
server
that
was
responding
to
a
query
could
include
a
pointer
to
another
server
that
would
provide
additional
information,
and
that
was
motivated
by
the
thin
domain
registry
use
case,
where
the
registry
would
return
some
information
about
the
resource,
but
also
include
a
pointer
to
the
registrar,
who
would
have
some
other
information
so
that
explicitly
addressed
the
idea
of
having
the
client
combine
two
responses
into
one,
but
there
wasn't
much
discussion
after
that
was
presented
next
slide.
Please.
A
A
A
B
B
A
J
D
Yeah,
sorry,
I
I
well
sorry
I
I
I
may
have
missed
this
in
this
presentation,
but
there
are
other
regional
registries
where,
where
this
is
a
requirement
and
and
is
there
going
to,
are
there
going
to
be
multiple
implementations
of
this
at
the
at
the
highest
level?
At
the
regional
internet
registry
level?.
A
B
D
B
Then,
with
that,
let's
go
back
to
our
chair,
slides
here.
I
believe
that
takes
us
through
the
new
work.
Adoption
requests.
So
you
know
these
are
just
opportunities
for
the
working
group
to
continue
to
move
forward.
Some
new
issues
have
come
up,
and
so
this
is
the
perfect
opportunity
to
move
into
a
discussion
of
our
milestones
and
what
work
we
do
have
on
our
list
here
and
what
all
of
that
means.
B
So
this
is
just
a
quick
picture
of
what
our
milestones
currently
look
like
just
so
that
people
can
remember
the
rdap,
reverse
search
and
the
registry
maintenance
and
federated
authentication
of
the
rdap
are
still
there
on
our
milestone
list.
You
can
see
that
the
rdap
reverse
search
is
woefully
behind,
so
we
certainly
ought
to
consider
moving
forward
that
particular
milestone
date.
If
we're
going
to
pick
and
continue
that
work,
that's
already
working
group
work
and
it's
already
on
our
list
here.
B
I
would
ask
that
the
federated
authentication
as
a
chair
asked
forward
that
we
probably
need
to
push
that
one
forward
again.
We've
been
carrying
that
waiting
for
you
know
some
work
to
start
in
in
in
icann.
You
know
some
interoperability
testing
and
work
there
to
start
to
move
that
forward.
Although,
as
scott
noticed
earlier
in
our
meeting.
C
B
B
So
that's
just
something
to
keep
in
mind
as
we
work
out
what
we
want
to
do
here
and
and
where
to
go.
So
let
me
first
go
back
over
to
antoine
here
to
you
want
to
jump
in
here
about
the
milestone
list
and
then
folks,
if
you
want
to
say
anything
in
the
in
the
you
know,
jump
in
for
a
discussion
here
and
add
any
comments
about
what
to
do
here.
Going
forward.
C
J
Given
how
small
our
working
group
is,
I'm
wondering
whether
it
would
be
more
efficient
to
like
concentrate
on
a
smaller
number
of
documents
at
a
time
and
three
to
get
them
through
in
like
a
shorter
period
of
time,
rather
than
like
keeping
seven
documents
open,
I
mean
yeah,
it's
just
a
consideration.
That's
it's
essentially
the
same
that
we're
trying
to
do
in
my
team
that
we
have
the
feeling
that
addressing
less
issues
at
the
same
time
leads
to
shorter
q
completion
time.
J
So
I'm
I'm
I'm
unsure,
but
but
typically
I
tend
towards
less
items
but
but
completing
them
in
a
shorter
time
frame.
Maybe
then
we
have
we
have.
We
can
have
shorter
periods
between
milestones
in
the
first
place,
yeah
if
we
address
something.
So
exactly
if
we
like
say:
okay,
the
only
thing
we
want
to
achieve
until
march
2021
is
the
art
up
search
at
the
simple
registration
reporting.
We
might
probably
make
that.
C
Yes,
and
and
the
question
of
course
alex
is
you
know
the
the
four
items
that
have
been
brought
up
to
the
working
group
now?
I
think
they
will
all
start
asking
for
adoption,
but
work
is
being
done
on
these
issues
anyway,
regardless
of
whether
we
put
it
on
our
milestone
list
or
not
it's
it's
just
of
you
know
the
formal
process
of
adopting
it
to
adopt
into
adopting
it
to
the
working
group
and
to
set
milestones
for
it.
L
B
You
say
you
know,
wherever
the
working
group
wants
to
do
it,
we've
sort
of
taken
the
approach
so
far
that
we
tend
to
take
them
on
and
then
try
to
move
them
forward
a
little
bit
at
a
time,
but
whatever
we
think
we
want
to.
Try
is
certainly
what
we'll
do
on
our
side
as
chairs,
so
yeah.
So
now
over
to
you,
jim.
F
B
Right
thanks
jim
that's
a
good
point
too.
One
of
the
reasons
for
having
multiple
documents
in
play
at
the
same
time
is
because
yeah
we're
a
small
group,
but
one
or
two
people,
you
know,
will
typically
work
on
each
document
and
there's
not
a
lot
of
overlap
there
in
in
that,
as
far
as
progressing
work
is
concerned,
alex
go
ahead.
J
Thank
you
jim
another.
Another
work
mode
that
I've
seen
in
a
lot
of
working
groups
is
that
as
soon
as
the
document
is
being
requested
to
adopt
it,
the
the
working
group
chairs
actually
asked
crowd.
I
will
take
five
names
of
people
who
are
committing
to
work
on
that.
That
has
proved
successful,
though,
in
a
little
bit
larger
working
groups,
I'm
afraid
that
if
we
do
that
here
it
might
be
the
same
five
names
on
each
of
the
drafts.
J
In
the
first
place,
we
don't
into
lots
so,
but
it
might
be,
it
might
be
to
to
to
ask
people
not
only
to
provide
a
document
chapter
as
soon
as
the
document
is
adopted,
but
also
provide
a
set
of
like
a
core
team
that
that
actually
works
on
the
document.
That
is
really
interested
in
getting
the
work
forward.
C
C
They
always
asked
for
about
five
people
who
want
to
work
on
a
document.
We
tried
this
at
the
beginning
with
three,
but
we
didn't
always
get
a
response
where
the
authors
still
wanted
to
progress
their
work.
So,
yes,
we
can
certainly
ask
that
during
the
adoption
process-
and
we
always
ask
the
question-
the
question
is:
what
do
we
do
when
we
set
a
limit
of
five
and
we
get
four?
Do
we
then
reject
the
adoption
of
the
documents.
J
J
B
B
I
think
this
has
been
a
really
good
meeting,
at
least
for
me
I'll
I'll
just
offer
some
thanks
to
everyone.
We've
had
a
particularly
productive
meeting
this
time
around
a
very
solid
agenda.
Good
good
technical
discussion
very
much
appreciate
that,
thanks
to
everyone
who
jumped
in
here
to
join
us,
we
have
some
actions
to
proceed
with
and
we'll
we'll
take
a
number
of
different
things
to
the
mailing
list
here
about
the
future
of
a
few
documents
and
what
to
go
forward.
B
C
Well,
I
don't
have
any
closing
remarks
too,
except
for
what
you
already
said.
I
want
to
thank
everybody
for
joining
this
meeting
and
we
will
continue
the
discussion
on
the
mailing
list
and
I
also
hope
that
next
time
there
won't
be
any
virtual
meeting
but
a
real
face-to-face
meeting,
and
thank
you
to
jay
for
already
proposing
the
t-shirt
for
that.