►
From YouTube: IETF112-REGEXT-20211110-1430
Description
REGEXT meeting session at IETF112
2021/11/10 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
All
right
welcome
everybody.
This
is
registration
protocols,
extensions
working
group,
I'm
here
with
my
co-chair
antoine,
and
we
only
have
an
hour
this
time.
However,
we
have
a
only
about
50
minutes
scheduled,
but
let's
and
I'll
just
jump
right
in
here.
I
guess
we'll
get
right
to
it
here
very
quickly.
The
note
well
you've
probably
seen
a
variety
of
versions
of
this
so
far
in
the
ietf.
A
This
is
our
standard
version
that
we've
been
using
all
along
and
other
groups
use
something
similar.
This
note
will
is
most.
This
particular
version
is
mostly
about
protections.
You
know
about
the
ietf,
your
contributions
status,
contributions,
patents
and
that
kind
of
thing.
It
only
has
one
comment
down
there
at
the
bottom
about
you
know
if
you
have
any
issues
with
how
you're
being
treated
at
all,
we
have
an
ombuds
team
that
you
should
certainly
go
to
and
in
fact
I'm
gonna
pop
up
this
extra
slide
here,
a
new
one.
A
A
You
know
professional
behavior
or
at
least
reasonable
behavior,
and
so
this
is
stating
the
obvious,
but
you
know
just
seems
important
to
put
the
obvious
up
sometimes
and
make
sure
that
we're
all
on
a
on
a
good
page
and
remind
us,
I'm
not
aware
of
any
problems
in
our
group,
but
then
again,
if
you
have
been
to
the
ombudsman
about
something
that
might
have
happened
here,
we
wouldn't
know
anyway,
unless
we
were
somehow
involved
in
it.
So
just
consider
this
reminder
and
please
make
sure
to
do
the
right
thing.
A
Okay,
let's
move
right
to
our
agenda.
This
is
our
standard
agenda.
Certainly,
agenda
bashing
can
happen
now
or
at
any
time
that
anyone
wants
to
jump
in
here,
but
this
is
what
we've
been
using
for
a
long
time.
You'll
see
here
that
we
have
50
minutes
and
a
little
bit
scheduled
for
today
in
our
one
hour
session,
in
fact
50
minutes
and
16
seconds.
A
A
D
A
E
A
A
lot
about
this
when
we
get
into
talking
about
our
existing
work.
You
know
antoine,
and
I
like
to
remind
people
that
as
part
of
adopting
documents,
we
really
would
want
to
make
sure
that
we
have
a
shepherd.
Other
working
groups
do
this,
and
this
is
something
we
we've
been
trying
to
do
here
along
the
way
we
will
get
a
discussion
about
a
new
document
potential
new
document
here.
A
I
want
to
make
sure
that
we
get
a
document
shepard
with
that
before
it's
adopted
and
a
milestone,
and
we
kind
of
neglected
that
with
one
of
our
last
documents,
but
we
need
to
figure
out
where
things
fit
like
that,
and
one
thing
to
mention
here,
an
additional
thing
that
we
haven't
really
said
before,
but
as
a
reminder
to
this
group
documents
move
along
when
people
have
energy
and
suggest
that
they
move
along
it's
important
to
keep
that
in
mind
it.
You
know
if
you
need
discussion
on
the
mailing
list.
A
Let's
have
that
discussion
if
there
are
issues,
but
after
that
it
really
is
up
to
the
document
author
and
editor
to
step
up
and
ask
for
a
document
to
move
through
the
process.
If
there's
no
more
discussion,
they
should
ask
for
last
call,
and
that
kind
of
thing,
and
just
as
you'll,
hear
some
requests
later
on
for
adoption.
You
know
again,
it's
really
all
about
the
document.
Authors
moving
things
along,
so
that's
a
useful
thing
to
keep
in
mind.
A
A
A
A
A
A
A
A
joint
interim
meeting
with
the
icann
technical
operations
group
back
in
october
20th,
we
had
quite
a
good
turnout.
There
we've
had
a
few
of
these
over
the
the
last
couple
of
years,
probably
had
one
one
a
year.
I
guess
the
last
couple
years
I
shouldn't
say
a
few.
The
reason
why
we
do
these
is
because,
as
we
all
know
in
this
working
group,
we
don't
get.
You
know
too
many
registries
and
registrars
that
participate
here.
A
We've
got
a
really
good
core
group,
but
we
don't
get
as
broad
exposure
as
we'd
really
like
to
get
so.
The
icann
tech
ops
group
has
a
very
broad
base
of
technical
participants
from
gtld
registries
and
gtld
accredited
registrars,
so
it's
very
helpful
to
expose
our
work
there
and
and
often
get
some
some
good
comments
about
it.
We'll
leave
it
to
the
individual
folks
here
who
were
there
at
that
meeting
to
say
anything
about
their
document
that
they
got
in
that
meeting.
It
was
only
an
hour
long.
We
had
10
minutes
of
document.
F
A
In
hopes
of
commenting
on
documents-
and
we
do
that-
I
do
that
fairly
regularly
in
the
tech
ops
group.
There
are
a
few
others
in
this
group
that
are
part
of
that
group
and-
and
we
all
like
to
do
that
at
technical
operations
meetings,
so
I'll
jump
up
to
my
document.
First,
there
myself
and
my
co-author
joseph
he
with
simple
registration
reporting.
A
G
G
H
H
Last
itf
meeting
next
slide,
please,
but
I
I
have
some
private
feedback,
first
feedback
coming
from
yazdeep,
so
I
expect
that
yazdeep
will
provide
a
further
feedback
on
the
many
least
just
correct
me.
If
I
am
wrong,
I
see
that
you
are
participating
the
the
meeting
and
but
the
next
steps
are
essentially.
G
G
I
Sure,
thanks
antoine
scott
holland
back
here.
Well
so
indeed,
just
earlier
this
week,
I
updated
the
draft
to
address
some
suggestions
made
by
mario
he's
done
some
implementation
work,
and
so
you
know,
of
course,
that's
always
valuable
feedback.
However,
there
were
a
couple
things
that
he
and
I
didn't
quite
agree
on,
because
they
would
be
much
more
significant
in
terms
of
changing
the
way,
queries
and
responses
are
structured
and
formed,
and
so
I
threw
that
out
to
the
list.
I
Folks,
if
you've,
you
know,
if
you
looked
at
this
draft,
particularly
if
you've
done
any
implementation
work,
I'd
really
value
your
opinions
in
terms
of
you.
Looking
at
those
suggestions,
letting
me
know
what
you
think,
I
mean
it's
not
that
they're
unreasonable
it's
just
that
they
they're
they're
big
changes.
So
please
take
a
look
share.
Your
feedback
on
list
it'd
be
greatly
appreciated.
H
H
The
main
changes
are
about
the
the
how
the
localizations
are
handled
in
in
just
contact,
so
how
can
be
entered
in
in
just
contact
inside
out
up
next
slide?
Please
so
I
changed
the
bit
the
the
the
list
of
the
map
keys
that
are
recommended
to
be
used
inside
just
contact
to
represent
some
information
that
they
mostly
used.
H
H
H
H
H
H
H
A
Yeah,
so
I
want
to
raise
a
question
for
this
group
here
with
respect
to
this
document
in
particular,
because
at
the
moment
this
document
doesn't
have
a
designated
status
to
go
to
with
respect
to
going
into
publication.
We
have
not
had
that.
This
is
the
one
document
we
actually
adopted.
It
expressly
leading
open
this
question
of,
should
it
go
onto
the
standards
track,
go
on
to
experimental,
be
informational.
A
A
Not
j
is
contact,
so
we
really
do
have
to
think
about
what
that
means
in
changing
the
standard
and
if
that's
really
where
we
want
to
go
so
we
don't
have
to
we're
not
going
to
solve
that
question
here
and
do
you
want
to
point
out
the
folks
that
please
do
comment
on
that
on
the
list
and
and
speak
to
that
question,
and
we
will
have
to
ask
that
question
and
get
an
answer
before
we
promote
this
document
to
a
working
group.
Last
call
thanks.
H
H
G
C
I
I
C
Okay,
thank
you.
Scott
murray.
Go
ahead,
just
maybe
to
help
you
answer
this
question
a
couple
of
things
I
noticed
section:
five
is
an
implementation
status
section.
Thank
you
for
including
it
I'm
glad
when
anybody
does
that
it
has
one
implementation
so
far,
which
describes
itself
as
a
proof
of
concept,
research,
implementation.
H
Yes,
I
know
that
this
would
be
a
the
the
document
in
presents
also
a
transition
for
replacing
the
jacod
with
js
contact,
but
at
least
in
my
opinion,
this
transition
will
be
completed
when
the
sun
condition
will
be
satisfied,
for
example,
a
number
a
large
number
or
implementation
of
js
content
in
adapt
instead
of
jakarta.
So
so
at
the
moment,
this
is
only
a
an
station
providing
the
information
in
an
alternative
format
with
respect
to
jakarta.
H
H
G
C
Purposes
of
this,
I'm
just
trying
to
sort
of
give
you
nudges
in
the
direction
of
should
this
be
proposed
standard.
Should
this
be
experimental,
the
things
that
we
would
look
at?
I
guess-
and
I
think
we'll
discuss
that
on
the
mailing
list
as
well
right
yeah,
that's
fine!
I'm
just
providing
input
thanks.
J
I
was
going
to
answer
mary's
question
by
saying
that
as
a
client
as
a
developer
of
a
rdap
client
or
that
browser
mobile,
I
intend
to
implement
gs.
Contact
gcard
is
a
pin
in
the
s
and
to
implement
just
gs.
Gs
contact
would
be
much
better,
but
you
know
it's
related
to
the
typical
chicken
and
egg
situation
right.
J
G
Thank
you
thank
you
mark,
and
you
know
look
looking
at
at
the
time.
I
so
I
think
the
the
the
ask
of
murray
was,
you
know
it
will
help
if
we
have
more
implementation.
I
also
see
in
the
chat
that
eduardo
is
saying
that
they're,
currently
monitoring
jazz
contact
could,
in
support
of
the
I
can't
read,
client
and.
G
He
says
definitely
would
help
if
there
were
more
implementation
to
test
parsing
responses
using
js
contact.
So
I
think,
mario,
if
we
can
get
some
more
implementations
in
there,
it
will
definitely
help
the
discussion
about
the
the
question
of
jin
remains.
We
should
really
look
at
what
the
status
of
this
document
is
when
we're
going
for
publication,
and
we
should
have
a
have.
F
G
Let's
see
where
I
needed
to
be.
Where
did
I
go?
I
think
I
was
somewhere
here.
So
thank
you,
mario
for
your
presentation.
I
don't
see
anybody
more
in
the
queue
you
can
turn
your
camera
off
now.
Yes,
thank
you,
then.
The
next
I
item
of
existing
work
is
the
use
of
internationalized
email
addresses
in
the
epp
protocol
and,
let's
see,
is
dmitry
in
the
meeting.
G
K
G
G
L
L
Some
of
the
things
that
have
been
added
is
an
explicit
report
for
js
contact,
support
for
registered,
name
and
reason
properties
in
the
json
value
registry
and
we've
added
handling
of
entities
with
multiple
roles
to
the
json
path.
Consideration
section
now
our
next
steps
were
determining
if
we
should
be
adding
rdap
search
if
it
should
be
added
to
the
draft.
L
There's
been
discussions
of
it,
but
we'd
really
like
to
talk
to
or
ask
the
working
group
if
that
should
be
added
jim
looked
at
the
changes
that
would
be
needed
and
we
would
need
to
change
specific
lookup
response
language
from
the
draft
we
need
to
replace
it.
We'd
also
need
to
use
relative
json
path,
expressions
for
search
responses
and
use
absolute
json
path,
expressions
for
lookup
responses,
and
then
we
need
to
provide
examples
of
unredacted
and
redacted
search
responses
to
go
along
with
the
unredacted
and
redacted
lookup
responses.
L
We
have
so
we've
discussed
it
before,
but
we
just
need
the
working
group
to
decide
if,
if
support
for
search
should
be
added
to
the
draft,
that's
the
only
known
issue
that
we
have
with
the
draft
and
then
we're
just
also
looking
for
additional
review
of
the
latest
version
of
the
draft,
which
is
it,
which
is
point
one.
I
believe,
that's
all
that
I
have
for
the
update.
M
H
H
L
G
K
Yeah,
what
was
the
question?
I
missed
the
question
that
needed
to
be
answered.
Do
you
have
that
question
for
mario
you
mean
yeah?
I
didn't.
I
didn't
actually
mean
to
answer
mario's
question,
but
if
you're
asking
me
to
do
it,
I
need
to
know
what
that
question
is.
Did
you
have
another
comment
to
make
james?
No,
I
did
because
I
saw
gestapo
wrote
in
the
chat
there.
He
asked
whether
or
not
to
consider
creating
a
separate
graph
for
searches
and
separate
one
for
lookup
and.
F
K
E
H
D
G
F
G
N
N
N
A
J
J
G
A
N
And
there
we
go
good
and
let
me
let
me
take
a
big
risk
here
and
try
to
move
into
presentation
mode
there.
We
go
okay
now,
which
one
you
see.
It
works
perfectly.
Okay,
good
all
right.
So
thank
you
very
much.
So
this
is
new
work
that
being
proposed
here,
and
the
bottom
line
is
to
create
a
an
iana
registry
of
dns
registration
data
elements.
N
This
is
not
intended
to
be
owned
by
our
project
or
indeed
any
other
projects
tended
to
be
a
a
sort
of
building
block
that
in
the
in
the
general
spirit
of
how
things
are
done
on
the
internet,
to
put
it
out
there,
and
then
anybody
can
draw
from
it
and
then,
of
course,
it
will
have
to
be
modified
over
time
as
people
want
to
add.
I
don't
think
there'll
be
too
much
withdrawing
of
data
elements,
but
from
time
to
time,
adding
new
ones
and
so
a
little
tiny
bit
of
governance.
N
The
answer
is
no,
it's
first
and
foremost
intended
to
be
aligned
with
what
exists
and,
second
of
all,
to
be
something
that
is
available
as
needed
or
as
desired,
but
not
to
act
as
a
forcing
function
at
all,
except
in
the
usual
way
that
when
something
is
there,
it
attracts
attention,
and
so
it's
a
sort
of
marketing
issue.
So
that's
the
the
basic
idea.
Let
me
give
you
a
brief
glance
at
what
the
initial
set
of
data
elements
that
we've
drafted
together
and
put
into
the
internet
draft.
N
But
it's
a
first
cut
and
I
will
not
all
be
surprised
or
unhappy
if
this
evolves
over
time
and
where
do
we
want
to
go
from
here?
Well,
quite
obviously,
we
would
like
for
this
working
group
to
adopt
this
as
a
work
item
and
to
emphasize
where
we
want
to
go.
This
is
not
a
protocol
per
se.
This
is
a
building
block
for
protocols.
K
What
the
problem
that's
being
solved
with
this,
we
have
data
elements
defined
in
epp
in
art,
app
and
data
escrow,
and
the
new
reporting
draft
has
the
capability
of
registering
data
elements
as
well.
So
is
there
an
intent
to
try
to
normalize
all
these
into
one
terminology
or
something
that
that
needs
to
be
enforced?
I
really
don't
get
what
problem
is
being
solved?
I'm
sorry,
thank
you.
K
N
K
N
One
quick
comment
that
there's
only
in
this
there's
only
one
in
the
case
that
you
have
multiple
contact
information
in
particular,
so
that
you
might
have
you
know,
an
admin,
contact
and
a
registrant
and
so
forth.
That
would
cause
a
duplication
of
types
of
fields
like
name
and
and
address
and
so
forth.
This
is
just
a
definition
of
those
and
then
out
of
a
particular
application.
D
D
Some
of
these
terms
are
mentioned
in
rdap
specifications,
and
I
would
offer
that
that
there
they
can
mean
different
things
in
different
contexts
that
the
the
term
of
what
these
these
different
things
mean.
One
is
what
uses
during
the
registration
process
and
then
rdap
is
what's
used
during
the
rdds
in
the
display
process,
and
so
they
can
mean
different
things.
D
I
would
be
worried
about
memorialize
these
things
in
itf
documents,
because
contracts
sometimes
refer
to
rfcs
and
give
them
status
in
a
way
that
that
can
have
unintended
consequences.
So
that's
again,
these
are
all
things
that
are
under
the
macro
comment
of
I'm
not
really
sure
what
problem
we're
trying
to
solve
here
with
this.
Thank
you.
O
Me
now
yeah
final
words,
so
my
question
is:
if
we
find
discrepancies
between,
let's
say
the
way
that
the
admin
contact
is
defined
in
in
rdap
and
data
escrow
or
whatever.
What
is
the
intention
in
this
new
draft
to
try
to
came
up
with
one
single
definition,
or
are
you
just
trying
to
capture
in
rdap
is
defined
as
this
in
epps
defined
as
this
in
whatever
rsc
or
document
is
defined
this
other
way?
N
A
third
literally
I
I
don't
think
the
purpose
of
this
is
to
force
anything.
Nor
is
it.
This
is
the
right
place
to
try
to
document
each
of
the
variations,
however,
where
there
are
the
same
idea
than
the
ideas
that
should
be
represented
in
or
named
in
the
same
way
and
where
there
are
different
ideas,
then
perhaps
the
best
thing
to
do
is
to
give
them
a
different
name
or
have
a
way
of
differentiating
them.
N
This
is
one
that
should,
as
I
say,
serve
as
a
building
block
and
any
mapping
of
these
two
particular
applications
or
how
it's
used
in
our
dap
in
one
way
and
a
registration
process
in
another
way
that
belongs
in
those
applications
and
in
the
documents
related
to
those,
but
but
to
the
extent
that
people
do
mean
the
same
thing.
It's
good
to
have
a
reference
to
build
on.
G
N
Give
different
names
to
them
or
you
know,
agree
that
one
means
what
you
want
and
the
other
doesn't
or
whatever
I'm
not.
I
don't
have
a
fixed
position
about
this.
It's
just
that
in
terms
of
regularizing
things
and
having
a
base
to
work
from
forcing
those
kinds
of
questions
to
the
surface
is
exactly
the
kind
of
thing
that
happens.
If
you
have
a
place
for
these
things
to
be
brought
and
dealt
with.
J
Yes,
just
wanted
to
say
that
you
know
I
have
another
act
and
we
actually
helped
the
space
industry
and
we
actually
run
registries
of
terms
and
abbreviations
using
space
space
industry
and
they
actually
had
you
know
multiple
definitions
and
for
the
same
keywords,
and
we
managed
that
and
by
having
that
registry
there
they
were,
they
started
a
few
years
ago
to
you
know
clean
this
up.
So
at
the
end
it
was
very
useful
for
them
and
it's
actually
going
to
be
an
iso
standard
soon.
J
G
G
The
one
thing
I
do
want
to
mention
is
that
you
know
we
are
all
for
standardizing,
and
our
charter
is
actually
explicitly
supporting
that.
However,
for
the
epp
and
rdap
protocols,
we
we
do
have
a
some
sentences
in
there
that
every
document
that
we
produce
should
be
as
widely
applicable
as
possible,
meaning
that
it
is
you
know
it's
about
registries
in
general
and
not
only
dns
registries.
G
In
your
list
of
examples,
for
example,
I
didn't
see
any
autonomous
system
numbers
or
route
objects
or
enum
registrations
in
there,
which
are
you
know
when
you
want
to
have
epp
and
rnap
to
be
as
as
as
broad
as
possible,
possible
registration
protocol
and
and
data
access
protocol.
It
shouldn't
only
be
about
dns
elements,
and
I
would
advise
you
know
if
you
want
this
to
succeed,
to
seek
support
from
other
ones
who
are
using
epp
and
rdap
to
find
the
missing
element
like.
N
That's
a
very
helpful
comment
I'll
take
that
as
a
as
a
friendly
amendment.
Certainly
no
objection
whatsoever
to
having
the
same
idea
expanded
to
cover
data
elements
that
are
needed
in
in
other
areas,
particularly
in
the
routing
and
addressing
communities
and
so
forth.
So
that
would
be
fine,
no
problem
whatsoever.
G
Steve,
I
think
we
will
continue
the
discussion
on
the
mailing
list
and
we
will
see
a
call
for
adoption
there
and
then
we
will,
at
the
end,
of
course,
have
a
vote
about
it.
But
I
think
there
can
be
some
some
more
discussion
on
the
mailing
list
to
see
if
it,
if
it's,
if
it's,
if
people
find
this
worthwhile
to
do
in
our
in
our
working
group.