►
From YouTube: IETF111-REGEXT-20210728-2130
Description
REGEXT meeting session at IETF111
2021/07/28 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
It
was
just
he
didn't
have
to
hear
me.
You
know
we
were
doing
great.
So
all
right,
it
is
half
half
the
hour.
So
let's
jump
in
it's
already
the
second
day,
the
ietf.
I
think
people
are
used
to
starting
on
time
here.
Yes,
recording
is
going
on
okay,
good
thing,
so
I'm
gonna
kick
off
this
meeting.
We
only
have
a
one-hour
meeting
this
time.
This
is
the
registration
protocols,
extensions
working
group
at
ietf,
111,
I'm
jim
galvin,
and
we
have
ant
wander
sharon
here
with
us.
A
Your
co-chairs
for
this
vigorous
and
engaging
working
group.
Thank
you
very
much
for
making
time
to
be
with
us
today
and
you
know
sorry,
I'm
just
having
a
little
bit
of
technical
difficulty
there
with
a
new
mouse,
okay,
so
quickly.
The
first
thing
to
get
to
is
no
no
well
going
to
move
ourselves
along
here,
smartly,
through
our
slides.
A
Basically,
it
does
mean
that
the
ietf
really
does
own
anything
that
goes
on
in
this
meeting.
Any
contributions
that
you
make
in
your
chat
room
over
audio.
That
kind
of
thing
please
do
pay
attention
to
our
anti-harassment
procedures
and
code
of
conduct,
and
with
that
we
will
move
on
to
taking
a
look
at
our
agenda
here.
A
A
A
A
Just
a
reminder:
we
have
in
general
adopted
a
guideline
that
other
working
groups
in
the
ietf
use
where
we
really
do
want
a
document
shepard
to
come
on
board
with
a
document.
When
we
take
a
document
on
we
do.
I
currently
have
one
document
on
our
docket,
which
does
not
have
a
document
shepard
at
the
moment,
but
you
know
we
don't
normally
do
that.
We
really
are
trying
to
to
help
facilitate
our
own
processes
here
and
you
know
getting
people
to
volunteer
to
do.
That
is
a
helpful
thing.
A
A
So
we've
had
four
documents
published
since
the
last
time,
including
the
other
half
of
data
escrow,
the
dnrd
objects,
mapping
document
we
have
epp,
unhandled,
namespaces
now
taken
care
of
and
put
out
there,
and
we
have
the
now
full
internet
standard,
rdap,
query
and
response
standards.
Specifications,
and
so
you
know
thanks
to
the
working
group.
You
know
congratulations
to
us
and
moving
those
documents
along
there's
one
more
in
the
rdap
series,
but
that
should
progress
between
now
and
the
next
meeting.
A
A
A
All
right,
excellent,
excellent.
Thank
you.
That's
good
to
know.
We've
had
that
document
around
for
a
bit
and
then
there's
the
secure
authorization
information
document.
It's
currently
an
isg
evaluation.
There
was
maybe
one
concern
for
the
working
group
to
consider,
but
it
was
benjamin
caduc
who
had
he'd
actually
withdrew
his
question,
so
the
document
can
move
along,
but
we
did
think
it
was
appropriate
to
see
if
there
was
anyone
who
wanted
to
say
anything
more
about
this
particular
issue.
He
was
raising
a
question.
A
G
G
The
concern
there
was
that
it
was
inconsistent
to
the
non-sponsoring
client
and
we
specifically
did
not
want
to
provide
an
indication
to
the
non-sponsoring
client
that
the
the
auth
info
was
set
or
unset.
So
in
that
scenario
the
auth
info
would
not
be
returned
to
the
non-sponsoring
client
and
in
the
case
of
the
sponsoring
client,
it
would
return
it
if
it
were
set
and
it
would
not
return
if
it
was
not
set.
G
Now,
as
far
as
when
this
particular
feature
was
added
to
the
draft,
I
look
back
and
this
was
added
in
zero.
Three
of
the
pre-working
group
document,
so
this
particular
feature
in
the
exact
language
in
the
draft
has
been
there
since
it
became
a
working
group
document.
So
I'm.
I
would
hope
that
the
working
group
had
has
had
opportunity
to
review
that
language
and
that
we
would
be
able
to
have
a
consensus
position
that
that
feature
is
fine.
G
C
G
A
A
So,
with
that
moving
on,
let's
move
into
existing
work-
and
in
this
case
we're
going
to
take-
you
know-
hopefully
not
more
than
five
minutes
a
document
to
jump
into
these
and
antoine's
going
to
take
over
the
meeting,
I'm
going
to
jump
right
in
first
and
just
give
my
quick
report
on
the
first
document.
There
simple
registration
reporting,
as
you
have
no
doubt
seen,
we
did
publish
a
new
version
in
time
to
just
meet
the
deadline
back
on
the
12th
and
thank
you
very
much.
A
There's
been
some
excellent
comments
on
the
list
and
we
will
continue
to
take
those
on
board
and
we
will
get
another
version
out.
There
were
some
comments
that
I
think
were
substantive
enough,
that
we
will
revise
the
document
and
then
look
to
see
if
there's
any
other
substantive
comments.
But
ideally
this
document
is
very
close
to
being
done.
So
after
addressing
the
comments
that
we've
just
gotten,
I
fully
expect
that
we
will
ask
for
a
working
group
last
call
on
this
document
and
just
to
be
clear
about
my
status.
A
C
F
G
Hey
jim,
I
had
posted
a
message
on
the
list
related
about
the
inclusion
of
the
concrete
reports
in
that
draft.
Are
you
planning
on
removing
those
reports
or
what
are
you
going
to
do
about
the
reports
themselves?
I
was
my
feedback
was
to
include
the
framework,
but
the
concrete
reports
themselves
should
be
removed.
A
A
The
report
specifications
came
from
a
number
of
documents
that
the
icann
tech
ops
group
had
drafted
and
put
together.
So
I
think
what
I
want
to
do
here
is
also
to
expose
this
document
one
more
time.
Maybe
we'll
have
a
joint
meeting
between
regex
and
techops,
as
we've
done
in
the
past
a
few
times
and
put
this
document
in
particular
on
the
agenda
and
have
some
broader
discussion
about
whether
or
not
to
remove
those
things.
So
I'm
I'm
hesitant
to
just
say.
Yes,
I
take
your
point,
but
I
think
we
were.
A
C
E
E
Only
two
slides
about
this
draft.
The
first
slide
is
about
the
versions
that
have
been
published
since
last
itf
meeting
the
zero
six
version,
the
zero
six
version
I
have.
I
have
updated
the
privacy
consideration
and
the
security
consideration
as
a
follow-up
of
the
feedback
from
from
the
last
meeting,
and
I
added
an
appendix
about
the
paradigms
to
enforce
access
controls
or
reverse
search
in.
E
E
According
to
this
proposal
to
the
deadline
to
comply
with
rain
data
access
about
evidence,
the
so-called
evidence
should
be
in
emergency
cases.
Maximum
16
hours
or
so,
and
we,
it
is
needless
to
say
that
reverse
research,
reverse
wheeze
in
particular
in
the
document,
is
one
of
the
is
maybe
the
most
important
capabilities
supporting
a
cyber
investigation.
E
C
The
privacy
considerations,
mario,
has
done
quite
some
work
on
it,
but
we
really
need
a
good,
proper
review
for
everybody
that
thinks
that
this
document
should
move
forward.
So
when
mario
will
propose
a
review
on
the
list,
I
propose
that
everybody
will
at
least
say
they
support
the
documents
and
I'm
happy
to
progress
with
it.
Mario.
H
Sure
this
is
scott
hollenbeck.
The
document
was
recently
updated.
It
was
getting
ready
to
expire,
so
I
had
a
couple
of
minor
changes
queued
up
made.
Those
mario
did
give
me
another
suggestion
for
clarification
that
I'll
be
incorporating
into
another
update.
You
know
when
the
opportunity
presents
itself,
but
yes,
we
really
are
kind
of
holding
off
on
this
one
to
make
sure
that,
for
example,
the
set
of
purposes
is
appropriate,
for
you
know
use
in
an
icann
context.
H
E
E
E
E
E
And
now
the
last
version
is
compliant
with
all
the
specifications
contact
specification
and
the
a
and
this
draft
in
particular,
so
you
you
it
is
able
to
assign
automatically
the
the
the
the
keys
as
described
in
the
previous
slide,
the
two
to
the
maps
without
any
particular
effort.
So
if
you
want
to
try
to
implement
these
drafts,
you
can
consider
this
library
if
you
are,
if
you
are
obviously,
if
you
are
java,
programmers
to
make
it
this
very
easy
to
implement
the
transition
between
from
card
to
js
contact
next
slide.
Please.
E
E
I
recently
made
some
tests
by
using
the
the
jackson,
library,
java,
jackson,
library
and
I
I
implemented
this
approach
without
any
particular
customized
customization,
so
I
it
took
me
one
hour
to
implement
this
approach
on
js
contact,
so
I
think
that
this
is
in
this
case
this
seems
to
be
the
the
most
flexible
approach
to
provide
localization
for
every
js
contact
content.
Just
contact
information
next
slide.
Please-
and
that's
all
from
my
side
about
this
proposal.
C
G
Rfc
5733,
where
email
is
required.
So
in
the
case
where
the
only
value
that
exists
is
an
internationalized
email
address
and
the
client
needs
to
create
the
contact
in
the
server.
What
should
the
client
pass
in
this
scenario
are
in
the
draft
that
specifies
the
use
a
placeholder
value?
That's
not
a
real
email
address.
It's
a
placeholder
and
an
indication
of
the
fact
that
the
only
email
that's
available
is
an
internationalized
one
and
the
server
doesn't
support
internationalized
emails.
So
therefore,
this
placeholder
value
is
sent
to
meet
the
needs
of
the
protocol.
G
Once
the
server
does
in
fact,
support
internationalized
email
addresses,
then
the
contact
can
be
updated
with
an
eai
address,
so
what
we
did
was
well.
I
posted
a
message
to
the
list
defining
the
set
of
requirements
for
that
placeholder,
as
well
as
a
proposal,
and
the
proposal
was
to
use
the
rfc7535empty.as1.
G
Domain
name,
which
is
a
black
hole
domain
and
then
to
add
on
their
eai
at
so.
The
whole
idea
is
it's
an
ascii
email
address
that
is,
that
will
not
have
any
mx
records,
will
not
go
anywhere,
but
it's
needed
only
when
the
email
is
required
by
protocol
and
the
only
value
available
is
an
internationalized
email
address.
G
C
G
That's
that's
the
proposed
definition,
because
if
you
look
at
the
set
of
requirements,
that's
posted
in
the
one
version
of
the
draft,
it
needs
to
be
an
ascii
email
that
would
match
validation
requirements
for
the
server.
It
also
can't
be
a
real
email
address,
because
it's
pretty
much
it's
not
the
real
email
address,
because
it's
an
internationalized
email
that
that
exists.
G
I
I
G
I'll
go
ahead.
Can
I
respond
to
that
yep?
I
I
ulric,
I
think
the
right
solution
of
this
is
for
you
to
support
internationalized
email
addresses.
Therefore
it
can
be
really
passed.
The
only
reason
why
that
placeholder
is
needed
is
the
fact
that
you
signal
that
you
don't
support
it.
So
if
you
support
it
as
a
server,
you'll
get
a
real
internet,
internationalized,
email
address
and
you'll
be
able
to
use
it.
I
G
G
I
G
I
A
B
A
Think
I
think
we
need
to
just
get
ahold
of
this
conversation.
I
understand
what's
going
on
here.
Let
me
offer
offer
the
following:
they
are
there.
We
are
crossing
a
boundary
here
with
respect
to
a
policy
concern
versus
a
technical
concern
and
there
are
as
a
as
a
policy
matter.
The
email
address
may
have
to
have
certain
certain
characteristics
among
them
being
that
it
has
to
actually
work.
J
E
A
Interaction
about
this
issue,
I
think
there
are
two
things
that
have
to
happen
at
this
point.
One
is:
we
should
actually
get
some
comments
from
the
email
community
and
we
do
have
some
advice
from
from
the
from
our
ads
about
a
way
to
go.
Do
that
and
the
chairs
will
take
that
on
as
an
action
to
make
this
document
visible
to
an
appropriate
set
of
people
to
get
a
reaction
from
the
email
community
about
the
use
of
a
placeholder
email
address
in
this
way.
A
On
the
issue
of
the
of
the
policy
concern,
I'm
you
know,
I
I
I
guess
I'm
not
sure
where
to
go
with
that
right
now,
and
I
think
that
we
need
to
take
that
discussion
to
the
mailing
list.
One
thing
that
I
would
suggest
about
it
all
is:
it
might
be
interesting
if
we
move
forward
in
a
joint
meeting
with
the
icann
tech
ops
group
in
part,
because
we
need
to
talk
about
the
registration
reporting,
it.
A
To
me
that
we
could
add
this
issue
as
a
discussion
point
there
just
to
get
some
interesting
viewpoints
from
other
registrars
and
other
registries
that
might
be
present
there,
and
I
think
that
that
will
also
inform
this
discussion
about
what
to
do
going
forward.
We're
not
going
to
make
the
decision
here.
A
G
A
C
Yeah
taking
it
to
the
list
for
further
discussion.
Thank
you,
jim
for
your
suggestions.
Moving
along
to
the
next
document,
which
is
still
existing
work,
is
the
rfc
7484
biz
document,
and
that
has
been
in
working
with
last
call.
It
has
been
closed
and
it
will
be
submitted
to
the
isg
isg
soon
as
well.
C
Yes
now
I
remember
it
passed
working
with
glasgow,
but
it
still
needs
a
new
version
of
the
document
before
we
can
submit
it
to
submit
it
to
the
isg.
So
this
is
really
a
call
on
mark
blanchet.
I
think
it's
holiday
season,
so
that
might
be
a
reason,
we're
waiting
for
the
next
revision
and
then
we'll
submit
this
one
to
the
iesg,
and
then
that
means
it's
done
for
the
standardization
work
of
the
art
app
service
right.
C
C
C
C
I
Yeah,
so
then,
yes,
so
registry,
lock,
automation
and
next
slide,
please.
So
a
small
problem
description
is
what
you
see
here
is
basically
the
flow
of
somebody
registering
your
domain.
You
are
a
customer,
you
go
to
a
reseller
orchestra,
we
try
to
register
domain
and
the
whole
flow
to
the
registry
and
back
is
fully
automated,
and
so
the
next
slide,
please.
I
I
So
what
registry
lock
tries
to
do,
and
I
I
realized
that
there
is
a
lot
of
names
for
this.
It's
registry,
log
and
registrar,
log
and
registrant
block-
and
you
know
all
of
this
if
you
want
to
have
a
really
good
overview
about
all
the
different
types
of
it.
The
center
has
done
a
working
group
and
they
have
had
a
real
good
document
about
all
the
different
types
of
blocking
that
are
out
there
and
how
they
work.
I
But
what
they
all
have
in
common
is
that
they
want
to
stop
the
automated
changes
to
domain
names
and
so
somewhere
in
the
process.
There
needs
to
be
a
manual
human
step
before
and
a
change
can
go
through
and
it
can
be
the
right
customer.
It
can
be
the
registrar
it
can
be
the
registry,
but
somebody
has.
K
I
Something
and
so
now
you're
wondering
didn't-
I
say,
registry
log
automation
in
the
beginning,
and
yes,
that
is
definitely
true.
So
what
we
try
to
automate
is
not
the
full
registry
log,
but
we
try
to
automate
the
locking,
not
the
unlocking
okay
next
step,
the
next
slide.
Please!
Yes,
so
there's
a
document
in
in
the
tracker
and
next
slide,
please
so
what
the
doc,
what
the
the
draft
says
is
that
you
can
chain
that
the
registry
log
once
the
domain
is
logged,
prevents
any
changes
to
the
registration
data
here,
so
update
commands
are
rejected.
I
Delete
and
transfer
to
mark
are
rejected,
but
renew
is
still
possible.
So
next
slide.
Please
and
so
domains
can
then
be
locked
with
a
simple,
lock
command,
either
when
they're
created
or
through
an
update
command
later
on
and
and
obviously
there's
no
unlock,
because
that
has
to
be
out
of
band
and
next
slide,
please
so
the
I
I
I
rejected
some
of
the
the
epp
stuff
here
that
needs
to
be
in
a
create
command,
but
but
you
basically
see
the
extension
and
it
says
block
and
that's
it.
I
I
So
that's
why
there's
only
out
of
band
and
next
slide.
Please,
yes!
So
then,
when,
when
you
temporarily
unlock
the
domain,
so
this
would
be
the
the
answer
for
for
an
unlocked
domain.
So
the
domain
is
permanently
unlocked
and
then
next
slide.
Please
we
have
the
locked
domain,
it
says
lock,
one
or
true,
it's
a
boolean
value
so
and
next
slide.
Please-
and
this
is
one
that
is
temporarily
unlocked
with
an
assessor
one
epp
command
and
to
this
point
until
this
point
in
time
it
will
be
unlocked
yeah
and
the
next
slide
please.
I
I
I
But
I
think
we
should
say
something
about
this,
because
if
the
policy
is
very
too
much,
it
will
be
really
hard
for
registrars
to
implement
this,
and
so
must
registries
support
the
epp
command
count
or
what
do
they
do
if
they
don't
support
it
so
and
how
are
domains
secured?
I
mean
if,
if
your
domain
is
locked,
but
the
name
servers
for
the
domain
are
not
blocked,
then
I
can
point
them
to
new
ip
addresses.
I
Would
this
be
a
problem?
How
should
we
handle
this,
or
should
we
just
you
know,
put
in
some
text
that
says?
Oh
look
at
this
too,
and
yes,
this
is
the
questions
that
I
would
really
like.
You
know
some
people
to
you
know
come
back
with
them.
You
know
input
how
they
would
handle
it
or
how
they
would
it
like
to
be
handled
and
yeah,
and
I
think
that
was
my
last
slide.
C
I
I
would
ask
for
adoption
and
feedback
so
because
I
think
we
should
work
on
this.
I
I
you
know
there
needs
to
be
some
response
from
the
community,
but
I
think
basically,
the
the
the
basic
process
is
very
easy
and
unsettled,
but
I
think
some
of
the
the
the
policy
stuff
around
this
needs
to
be
discussed
somewhere
and
yeah.
I
C
K
Thank
you,
alexander
mayor
from
eighty
on
the
questions.
I
think
you
listed
a
really
hard
questions
already
and
I
think
those
questions
are
indeed
pretty
much
policy,
so
they
shouldn't
be
the
epp
extension.
I
think.
On
the
other
hand,
the
information
that's
conveyed
in
the
epp
extension
is
connected
to
the
policy,
of
course.
K
K
We
we
get
away
without
an
epp
and
because
we
understood
that
the
only
purpose
of
dpp
extension
is
switching
the
registrar
log
on
then
it's
a
very
a
very
narrow
part
of
the
business
process.
That
probably
only
works
well
as
soon
as
there
are
other
registries
also
using
an
epp
extension
yeah
get
the
point.
If.
K
K
I
think
I
would
support
adoption
in
the
near
future
yeah
if
that
makes
sense,
because
I
see
more
and
more
registries
implementing
registry
lock
or
register
lock,
and
so
in
the
near
future.
There
will
be
more
people,
be
able
to
comment
on
the
split
between
policy
and
so
on
and
so
forth,
and
the
subway
tell
us
we
can
keep.
D
K
L
Get
my
preferences
there
thanks
real,
real
briefly
rick
wilhelm
verasan,
I
think
so
registry
lock.
I
think
that
there's
a
lot
of
general
agreement
that
it's
a
good
thing.
However,
I
don't
think
I
think
that
we
should
look
long
and
hard
about
enabling
registry
lock
via
epp,
because
it's
a
mechanism
that
actually
helps
protect
against
the
the
registrar's
epp
channel
being
compromised,
and
so
even
the
notion
of
locking
it
over
epp
is
something
that
can
lead
to
inadvertent
consequences.
L
For
example,
if
a
a
bad
actor
changes,
name
servers
and
then
also
goes
in
and
subsequently
locks,
the
name
that
can
lead
to
unintended
consequences,
essentially
a
denial
of
service,
because
it
makes
it
more
difficult
for
the
legitimate
registrant
registrar
to
flip
things
back
so,
overall,
the
notion
of
registry
lock,
being
an
out
of
band
thing
and
outside
of
epp,
is
actually
a
feature
rather
than
a
bug.
So
I
think
we
should
think
hard
before
looking
at
standardizing
a
way
to
do
it
over
epp.
C
J
Can
you
still
hear
me
test
test
one
now?
We
can
still
hear
you.
Yes.
Thank
you
all
right,
very
sorry
about
that
guys,
I'll
I'll,
be
quick
this
this.
What
we're
requesting
is
a
way
to
redact
our
dap
fields
because
of
various
privacy
privacy
policies
that
have
been
enacted
by
several
countries.
Certain
contact
values
can
no
longer
be
returned
in
rdap
responses
based
on
a
client's
privileges.
J
For
example,
the
contact
name
address
email
phone
number
is
now
returned
for
contacts
of
certain
countries
for
domain
registrations.
Now,
because
of
that,
some
of
the
I'm
sorry
some
of
the
rdap
clients
have
asked
well.
How
can
we
tell
since,
since
nothing
is
returned
for
those
for
those
fields?
How
can
they
tell
if
there
was
actual
field
value
that
was
entered
or
if
the
registrant
just
did
not
enter
any
information,
because
of
that
we've
discussed
putting
in
values
of
redacted
or
redacted,
due
to
government
or
privacy
policies
etc
into
each
of
these
fields?
J
In
order
to
signal
that
the
actual
value
was
redacted
due
to
policy,
but
doing
that
would
break
the
expected
format
of
some
of
these
fields.
For
example,
the
email
and
phone
fields
would
not
be
formatted
as
an
email
or
phone
number
correctly,
and
that
would
lead
to
could
lead
to
issues
with
rdap
client
parsing.
J
So,
in
order
to
address
some
of
these
issues,
the
solution,
this
solution
would
allow
fields
to
be
blank,
thereby
not
breaking
any
type
of
format.
Parsing.
The
solution
is
to
create
an
rdap
extension
that
would
identify
the
redacted
rdap
response
fields
using
a
json
path
as
a
default
expression
language.
This
would
then
allow
requesters
to
be
able
to
differentiate
between
a
field
being
null
because
because
a
registrant
did
not
enter
any
information
or
if
the
field
was
null
because
it
was
redacted.
J
C
C
J
C
C
A
A
It's
not
just
about
whether
data
is
present
or
not.
You
need
to
indicate
there
needs
to
be
a
way
in
the
response
to
indicate
that
there
is
data,
but
you
can't
have
it
and
that's
really
all
that's
going
on
here.
It's
just
an
extension
that
gives
you
the
opportunity,
as
a
responder
as
a
server,
to
be
able
to
give
a
client
more
information
and
give
them
that
data
point
that
there
is
data,
but
I'm
not
going
to
give
it
to
you
and
it
is
needed
by
a
variety
of
policies.
A
So
it
really
is
an
implementation
issue.
It's
just
adding
another
feature
to
rdap,
that's
not
there,
but
it's
not
required.
Obviously,
whether
or
not
one
uses
it
and
how
you
use
it
is,
you
know,
completely
a
policy
decision
and
a
matter
of
local
implementation,
so
I
just
wanted
to
offer
that
out
there
here
on
the
on
the
list.
Thank
you.
C
C
I
guess
not
it's
button
choosing
time
right.
Okay,
if
there
is
no
any
other
business,
then
we
are
three
minutes
late
in
this
shorter
meeting.
I
hope
that
next
time,
when
everybody
is
preparing
for
the
meeting,
please
give
us
a
heads
up
in
time
for
us
to
judge
the
agenda
time
that
we
need.
We
just
made
it
three
minutes
over
time.
Now,
if
there's
no
other
any
other
business,
then
this
will
be
meeting
adjourned
and
thank
you
for
taking
diminished
research.