►
From YouTube: IETF113-REGEXT-20220322-1200
Description
REGEXT meeting session at IETF113
2022/03/22 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
C
A
Okay,
anyway,
I'm
letting
myself
get
distracted
here
I
got
to
get
to
yeah.
B
B
So
jim,
shall
I
shall
I
open
the
meeting
then
and
sure
yeah
you
do
the
the
upload
of
the
presentation.
F
There
in
a
moment
alex
the
mobile
app
doesn't
show
the
session
for
whatever
reason
anyway,
or
maybe
it's
just
me
on
the
agenda-
it's
there
yeah,
but
on
the
mobile
app,
it's
not
there.
So
maybe
the
schedule
and
oh
well.
A
Okay,
you
should
check
the
meeting
materials
antoine
and
make
sure
that
you
now
see
the
data
dictionary
slides
or
do
we
have
to
ask
meat
echo
to
reload
again
of.
B
A
B
Have
to
you
have
to
reload
them
from
there
there
now
and
now
see
so
they
are
there
now
and
now
we
only
have
to
wait
when
we
do
the
next
presentation
to
see
if
they're
there,
but
okay,
since
we're
already
two
minutes
over
time.
Let's
open
the
meeting.
This
is
the
registration
protocol,
extensions
working
group.
B
A
A
Do
the
introduction
right?
That's
right!
I
have
to
do
the
introduction.
We
have
four
minutes
here,
we're
not
we're
not
over
time
yet
not
over
time
yet,
but
it
is
antoine's
birthday
today.
This
is
a
very
special
day
for
him.
So
you
know
it's
a
shame
that
you
can't
be
in
vienna
and
go
out
and
celebrate
in
style,
yeah
yeah
too
bad
I'll,
be
at
the
next
one
right.
A
B
Skip
the
note
well,
but
they're
still,
they
should
read
it
and
they
should
adhere
to
it.
I
think
everybody
has
read
the
note.
Well
everything
you
say
here
in
the
meeting
room
on
the
mailing
list
or
in
the
corridors
is
subject
to
the
idf
notewell,
so
read
it
well
and
of
course,
we
one
of
the
things
as
well
is
the
idf
code
of
conduct
guidelines,
which
I
present
on
the
screen
now,
which
basically
means
you
know,
treat
college
with
respect.
B
B
Then
that
is
the
welcome
introduction.
Usually
we
say
another
word,
and
that
is
the
way
that
we
do
document
management,
which
means
that
we
expect
people
to
read
and
react
to
documents
on
the
mailing
list.
Everybody
that
has
once
written
a
document
will
be
happy
to
to
to
see
contributions
there.
We
also
have
the
process
within
this
working
group
that
once
a
document
is
adopted,
that
we
request
to
have
a
document
shepard
right
from
the
start
of
document
adoption
and
not
at
the
end
when,
when
we're
going
into
the
working
group
last
call.
B
So
if
you
submit
a
document
for
adopting
by
this
working
group,
we
kindly
request
you
to
search
for
a
document
shepard
for
your
document,
which
is
not
the
document
author
or
any
of
the
chairs
of
ads
and
for
the
people
that
want
to
volunteer
being
a
document
shepard.
It's
a
very
good
opportunity
to
learn
everything
about
the
processes
of
the
itf
and
and
get
to
know
the
especially
the
process
of
how
a
document
is
going
along
in
the
in
the
publication
process.
B
We
have
a
few
documents
that
are
published
since
the
last
idf
one
of
them.
These
is
the
secure
authorization
of
information
for
transfer.
Rfc
9154,
as
you
can
see,
on
the
screen
and
the
other
one
is
original
registry
maintenance
notification.
B
First
is
finding
the
authority,
the
registration
data
for
the
rdap
service.
This
is,
as
you
all
know,
an
elevation
to
standards
for
one
of
the
the
other
documents,
it's
very
close
to
being
published.
It's
still
in
the
rc
at
the
queue.
I
didn't
see
any
messages
today,
but
expect
this
one
to
be
published
within.
I
think
the
next,
the
next
days
or
week.
B
This
document
has
passed
working
group
last
call,
but
we
are
during
working
group
last
call
this
document
changed
a
few
times
and
we
assume
that
this
is
for
that
that
it
didn't
change
anything
substantial,
which
is
why
we
we
want
the
document
shepard
to
state
that
on
the
mailing
list
and
then
do
his
write-up
before
we
can
submit
this
to
the
isg,
and
I
see
james
gould
in
the
queue
there
james
go
ahead.
A
Well,
if
you
can
type
your
comment
in
the
chat
room,
jim,
we'll,
we'll
read
it
out
for
you.
B
Okay,
I
don't
see
jody
in
the
participants.
B
Yeah
so
james
said
in
the
indie
chat.
You
know
nothing.
Material
was
changed
to
the
draft.
We
know
this,
I
mean
jim
and
I
have
read
the
draft
too.
We
think
that
there
is
not
no,
that
there
are
no
material
changes
made
during
last
call,
but
since
we
jim
and
I
need
to
be
impartial
here,
the
process
is
that
the
document
shepard
is
supposed
to
state
that
as
an
independent
reviewer
and
basically
we're
waiting
for
that,
and
then,
when
jody
has
done,
that
he
should
also
do
the
write-up.
As
the
document
shepherd.
B
But
since
jody
is
not
in
the
room,
jim-
and
I
will
continue
to
harass
him
on
that
and
to
make
sure
that
that
he's
doing
that,
but
so
if
anybody
is
aware
that,
if
anybody's
asking
why
this
is
taking
so
long
at
the
moment,
it's
it's
on
the
document
shepard.
If
it
takes
much
longer,
we
might
want
to
look
for
another
document
shepard,
but
let's,
let's
first
give
jody
a
fair
chance
to
do
this.
B
Then
we
change
use
jim
and
you'll
do
it
from
from
here
on
for
the
existing
work,
because
I
think
the
first
one
that's
on
the
list
is
the
simple
registration
reporting
and
you
are
the
one
to
state
something
about
the
progress
of
this
document.
A
A
We
really
would
just
like
for
folks
to
add
a
bullet
whenever
you
hear
an
interesting
point
and
just
put
that
in
the
in
in
the
notes,
so
we're
just
gonna
depend
on
the
recording
in
the
chat
room
here.
To
keep
us
honest
and
the
note-taking
facility
is
is
just
for
capturing
actions
and
decision
points.
A
A
A
A
Yeah,
simple
registration
reporting
very
quickly.
We
believe
this
document
is
ready
for
working
group
last
call
and
we're
going
to
be
asking
for
that
on
the
mailing
list
after
the
ietf
year.
It's
going
to
get
added
to
a
list
of
several
documents
here
are
on
the
cusp
of
working
group.
Last
call
so
we're
ready
to
move
that
along
as
soon
as
other
folks
are
ready.
There
really
hasn't
been
much
discussion
with
the
document,
and
I
see
tim
with
your
hand
up.
Do
you
wanna,
try
again
jim.
A
Okay,
well,
you
know
back
to
you
antoine
about
registration
reporting,
we'll
let
jim
keep
trying
or
if
you
put
a
comment
in
the
chat,
we'll
deal
with
it.
There.
Sorry,
jim,
not
sure,
what's
going
on.
B
B
But
you're
unmute,
okay,
next
one
is
the
reverse
search
capabilities
and
that
is
mario,
mario
alfredo.
I
think
I
saw
you
in
there.
I
saw
you
earlier
this
week.
Do
you
hear
me
yeah?
We
can
hear
you
mario.
G
Okay:
yeah!
Yes,
yes,
since
last
meeting,
I
added
the
dota
t,
add-up
web
client
to
the
implementation
status
section
and
following
the
up
the
feedback
from
jazdick
and
tom,
I
extended
the
query
model
to
represent
a
reverse
reverse
search
based
on
any
relationship
between
the
rdap
object
classes,
and
I
changed
the
the
role
path
segment
into
a
query
parameter
now.
I
think
that
the
document
is
is
in
good
shape
and
is
substantially
ready
for
to
go
into
the
working
group.
Last
call.
B
Okay,
very
well,
so
conclusion
for
this
talking,
you
think
it's
ready
for
working
good
glass
call.
We
saw
your
request
for
that
and
we
will
follow
up
on
that
on
the
mailing
list.
After
this
yeah
itf
meeting.
B
Think
that
you
agree
yeah
thomas
is
the
document
shepard.
We
we
already
discussed
this
with
him
that
this
document
has
a
quite
long
reputation,
especially
for
the
privacy
considerations.
Section
he's
all
aware
of
that.
So
we'll
be
expected
to
have
this
in
working
group
last
call
in
the
next
weeks,
then
the
third
document
federated
authentication
using
open
id,
is
scots
in
the
room
or
in
the
meeting
scott.
Do
you
want
to
make
comments
for
this?
One.
C
Sure,
antoine
I'm
not
in
the
room,
I'm
remote,
yep
yeah.
So
so
this
document
changed
extensively.
C
I've
got
a
few
more
minor
changes
to
make
based
on
feedback
received
from
the
last
update,
but
once
I
make
those
changes,
I
think
we've
got
a
document.
That's
in
really
really
really
good
shape.
The
only
other
thing
I'd
like
to
ask
people
to
look
at
is
the
list
of
query
purposes
that
are
currently
there.
Those
are
part
of
a
proposal
for
an
iana
registry
of
query
purposes,
but
if
we
agree
that
those
purposes
you
know
cover
the
use
cases
we're
familiar
with,
I
think
this
document
will
too
will
be
ready
for
working
group.
B
G
Yes,
I
just
made
only
editorial
changes
since
last
meeting,
so
I
correct,
I
update
the
references
due
to
the
transfer
of
the
js
contact
document
from
jmf
to
collect,
but
nothing
else.
So
I
don't
know
if
now
it
is
the
right
moment
right
time
to
ask
for
the
working
group
last
call,
because
the
guest
contact
documents
are
expected
to
a
schedule
to
to
go
into
working
group
law
school
next
july.
G
So
I
don't
think
that
there
will
be
a
important
changes
in
the
in
the
next
until
july
in
the
in
this
document.
So
I
would
suggest
to
go
into
working
group
last
call,
and
I
know
that
there
is
obviously
a
a
deep
er
sun
to
depend
in
two
dependencies
from
the
js
contact
documents.
It
seems
to
me
normal,
so
I
don't
know
what
is
the
the
the
right
procedure
in
this
case?
B
Yeah
yeah,
thank
you,
mario
yeah,
for
for
folks
that
didn't
didn't
get
this.
Yet.
There
are
two
normative
references
in
this
document:
two
internet
drafts,
which
of
course,
are
not
allowed,
and
so
we
are
actually
waiting
for
the
the
two
other
drafts
which
are
not
in
this
working
group
but
they're.
Another
working
group
on
js
contact
to
be
published
together
with
this
document
in
one
go
and
therefore
we
have
normative
references
to
rfcs
and
not
to
to
to
internet
droughts.
We
already
discussed
this
with
with
murray
our
area
director.
B
He
says
it
won't
be
a
problem,
they
will
just
queue
up,
and
so
we
can
do
the
working
group
last
call
but
be
expected
not
to
to
have
them
published
until
the
other.
Two
documents
are
to
be
published
as
well,
and
I
see
murray
in
room
murray.
I
don't
know
if
you
want
to
add
anything
to
that.
B
B
Okay,
so
yes,
that's
the
status
of
the
pro
of
the
of
of
this
document.
It
means
that
we
can
go
into
working
group
last
call
with
this
one,
but
it
is
in
no
hurry
at
all,
since
we
have
to
do
this
before
july,
when
the
other.
H
B
Documents
will
also
be
be
published
in
the
other
working
group,
so
I
propose
that,
since
we
have
already
three
requests
for
working
group
last
calls
we
can
do
this
one
after
the
other
three,
if
you're,
okay
with
that,
mario
and
because
it
will,
it
will
be
linking
lingering
around
anyway
no
problem
at
all
yeah.
B
B
If
I'm
correct,
I
have
to
scroll
down
the
whole
no
they're,
both
not
here.
So,
let's
deal
with
this
one
further
on
the
mailing
list.
I
don't
th.
This
one
is
not
in
working
group
last
school.
Yet
if
I'm
correct,
there's
still
work
in
progress
here
to
be
done.
B
So
that's
that,
let's,
let's
let's
just
keep
that
there
then
the
next
one
is
the
registration
data
dictionary.
I
don't
know
jim.
Did
you
find
the
slides
already?
B
I
I
But
heather
you
and
I
are
gonna
switch
off,
maybe
if
jim
could
run
the
slides
we'd
both
be
in
better
shape.
B
A
Yeah,
can
we
ask
meet
echo
to
to
to
reload
the
pre-loaded
slides,
and
I
want
to
give
rick
a
chance
to
go
back
to
the
previous
document
and
say
a
word
while
we're
waiting
for
that.
He
wrote
a
comment
in
in
the
chat
room,
which
is
kind
of
important
I'd
like
to
give
him
a
chance
to
to
speak.
That.
K
J
Okay,
very
good
thanks
so
yeah
rick
wilhelm
pr,
just
for
the
wearing
my
rdap
working
group,
chair
hat,
just
letting
everybody
know
what
I
said
in
the
in
the
in
the
chat
there
that
the
icann
rdap
working
group
is
working
on
modifying
the
I
can
rdap
profile
so
that
rdap
responses
are
allowed
to
use
js
contact
and
are
not
required
to
use
j
card.
J
This
will
probably
make
a
lot
of
folks
in
the
room
that
are
not
big
fans
of
jay
card,
pretty
happy,
so
we're
allowing
flexibility
there
in
the
response
mechanism,
and
so
we're
kind
of
hoping
that
that
would
it's
not
required
that
they
use
js
contact,
but
it
certainly
allows
that
optionality
and
so
we'll
we're
hoping
that
we're
going
to
start
to
see
some
variety
and
implementations
and
an
evolution
in
the
in
js
content
implementation.
J
I'm
probably
going
to
learn
some
things
in
that
and
so
happy
to
take
any
questions
about
that,
but,
and
and
also
a
lot
of
shout
out
to
mario
on
that.
Thanks.
B
A
You
rick,
and
I
now
have
thank
you
meat
echo.
I
now
have
the
the
data
dictionary
slides
so
over
to
you
guys.
D
Outstanding,
so
we're
we're
going
to
assume
that
folks
have
had
a
chance
to
read
the
data
dictionary
jim.
Could
you
go
to
the
next
slide
please?
D
So
when
last
we
left
our
humble
explorers
since
ietf
112,
the
draft
was
accepted
as
a
working
group
item.
Thank
you
all
very
much
for
that.
For
my
own
purposes
of
keeping
track
of
feedback,
I
did
go
ahead
and
create
a
github
repository,
not
suggesting
changing
working
group
process
on
how
you
normally
handle
drafts.
This
was
as
much
for
me
personally
as
anybody
else,
but
it's
there
if
anyone
would
like
to
follow
along
if
they
would
find
that
easier.
D
What
changes
we've
made
as
as
a
result
of
the
feedback
that
came
for
the
call
to
make
this
a
working
group
item,
we
updated
the
abstract
one
of
the
big
points.
Was
we
really
don't
want
to
set
policy
with
this
draft?
So
we
tried
to
make
that
clear.
D
We
updated
several
of
the
definitions
to
remove
the
normative
reference
to
the
epp.
Spec,
the
general
data
element
specification.
We
made
a
note
that
local
interpretation
is
expected
for
any
any
legal
issues,
and
this
this
in
no
small
part,
touched
on
questions
of
you
know
legal
natural
person.
What
not?
What
is
what
is
the
local
definition,
because
the
data
dictionary
isn't
trying
to
set
that
there
were
several
areas
that
could
inform
policy
just
by
how
they
were
defined
and
for
all
of
those
we
put
the
definition
to
to
be
determined.
D
We
also
did
to
be
determined
for
any
elements
that
that
had
questions
about
what
format
are
you
choosing
so
for,
like
date
or
name
or
address?
D
That's
those
are
always
sticky
to
to
define
well,
so
those
are
also
tbd
and
given
the
previous
changes,
we
moved
several
items
from
normative
references
to
just
informative
references,
because
they're
they're
no
longer
fundamentally
required
next
slide.
Please,
there
are
a
couple
things
that
we
were
able
to
just
close
in
terms
of
requests
that
people
made
for
as
part
of
the
call
for
adoption.
One
was
to
change
the
title
from
the
dns
registration
dns
data
dictionary
to
the
registration
data
dictionary.
D
D
I
Thank
you
very
much
heather.
Let
me
just
emphasize
a
pointer
to
this.
Work
arose
out
of
work
that
heather
and
I
and
others
have
been
involved
in
where
we
realized
that
we
were
making
references
or
making
lists
of
data
elements
and
that
there
are
other
places
in
the
ecosystem
where
there
are
references
to
the
equivalent
data
elements
and
that
there
was
no
common
place
to
refer
to
those.
I
So
this
is
sort
of
a
an
emergent
aspect
of
the
work
and
the
intent
which
I
want
to
emphasize
very
strongly
is
that
this
is
not
intended
to
influence
any
of
the
substantive
developments
going
on
in
these
areas.
It's
simply
an
attempt
to
gather
the
terminology,
that's
used
and
provided
as
an
available
source
of
commonality
across
the
system.
I
I
know
that's
a
question
that
keeps
coming
up
as
to
whether
or
not
we're
trying
to
change
things
that
have
been
developed
or
influence
existing
things,
so
we're
just
trying
to
put
something
on
the
table.
That
would
be
a
useful
building
block
for
either
existing
or
future
systems
and,
of
course,
we'll
see
how
that
goes.
So
here's
some
of
the
comments
that
came
back
and
and
the
first
one
I
think
I've
just
spoken
to
that
this
documents
various
terms
but
not
expected,
necessarily
to
be
in
complete
agreement.
That
was
a
suggestion.
I
Another
concern
is
that
definitional
nuances
might
be
lost.
Many
words.
Very
policy
loaded
can
be
difficult
to
capture
a
standard
definition
for
them.
That's
true
and
will,
as
I
said,
we're
trying
hard
to
be
as
as
neutral
and
as
sort
of
vanilla
as
possible
in
these
definitions,
a
concern
about
whether
there
are
implied
policy
decisions.
I
The
comment
was,
it
says
it's
merely
a
dictionary,
but
then
it
goes
on
to
make
very
clear
policy
decisions.
E.G
and
section
2.30.
I
Well,
I'm
not
sure
what
more
I
can
say
with
respect
to
the
first
of
those
things,
but
with
respect
to
the
second,
that's
an
interesting
and
in
some
ways
a
quite
insightful
comment
that
just
by
putting
those
definitions
in
there,
it
provides
ammunition
for
parties
who
want
to
argue
well,
it's
defined.
Therefore
it
must
be
used.
I
No
doubt
there
will
be
instances
of
that
kind
of
dialogue,
but
I
hope
we're
making
it
clear
in
here
that
that
is
a
separate
and
an
explicit
decision
that
has
to
be
made
by
each
and
every
group
as
to
whether
they
want
to
use
those
data
elements,
and
one
of
the
things
that
I
think
will
sort
of
make.
That
case
is
that
there
will
be
plenty
of
data
elements
that
are
defined
that
simply
will
not
be
used.
I
It
would
be
strong
agreement
not
to
use
it
in
a
particular
application.
So
I
think
that
would
be
it'll
be
easy
to
push
back
in
those
situations
where
somebody
is
trying
to
say
well,
it's
there.
Therefore,
you
have
to
use
it
and
the
answer
is
no.
It's
got
to
be
much
stronger
than
that
next
slide.
Please.
I
Jim
there
we
go
a
question
about
the
use
of
a
label
formats,
international
version.
U
label
seems
to
be
more
inclusive.
I
I
actually
am
going
to
punt.
I
remember
listening
to
some
discussion
about
that,
but
I
realize
I
don't
have
the
full
picture
of
that.
There
are
some
others
in
the
room
here
who
might
be
able
to
speak
to
that.
I
Feel
free
to
speak
or
chat
or
whatever
and
with
respect
to
the
second
bullet,
is
the
goal
to
describe
the
semantics
of
daniel
also
specified
syntax.
In
the
last
case,
we
need
to
specify
unicode
normalization,
so
I
would
expect
that
this
will
be
come
out
in
the
back
and
forth
that
we're
going
to
have
as
we
move
forward
on
all
of
this.
A
Yeah,
jim
gold
had
his
hand
up
briefly,
but
I
I
will
also
comment
that
the
issue
in
in
my
mind
about
a
label
versus
you
label
is,
is
just
that
you
probably
have
to
have
both,
because
even
in
the
gtld
space,
where
you
get
policies
from
icann,
they
only
apply
at
the
tld
level
and
some
limited
application
at
the
second
level.
But
you
can't
control
anything
else
down
the
tree.
L
M
Something
yeah
yeah,
I
think
kind
of
yell,
okay,
so
yeah.
No.
I
actually
want
to
speak
to
the
second
bullet,
not
the
first
one,
because
I'm
a
little
bit
confused
of
the
purpose
of
this
draft
because
it
has
a
mix
of
syntax.
M
M
I
I
don't
think
we're
going
to
resolve
it
on
the
spot
here,
but
we'll
make
a
point
of
having
some
dialogue
on
the
on
the
mailing
list.
I
Suggestion
clarifying
iana
considerations
clarify
that
new
data
elements
will
be
created
for
use
across
the
entire
domain
system,
as
opposed
to
describing
how
specific
data
element
is
populated
for
a
given
domain,
and
I
have
to
add
quickly
that
we're,
although
this
arose
out
of
work,
that
we're
doing
in
the
domain
name
system.
It
applies
also
to
data
elements
for
address
registrations
and
and
potentially
for
other
situations.
So
we
need
to
make
that
a
bit
clearer
word
domain.
I
There
might
might
seem
like
it
means
domain
names
and
I
think
we'll
we'll
pull
that
out
a
little
bit.
I
All
right
several
next
steps,
I
need
text
oops.
What
happened
here.
A
M
Different
issue
I
want
to
bring
up
so
just
trying
to
find
the
right
time
to
do
it.
Thank
you.
I
Yeah
and
there
you
go
excellent
recovery,
all
right,
so
a
handful
of
next
steps.
Obviously
we
want
to
fill
in
the
tbds
and
identify
any
terms
that
are
missing,
although
my
strong
expectation
is
that
this
is
a
live
process
that
once
we
put
this
to
bed
and
and
get
the
registry
up
and
running,
there
will
then
be
additional
data
items
that
will
get
added
at
some
rate
won't
be.
I
It
won't,
be
a
torrent,
but
might
be
a
little
trickle,
but
there
will
there
will
be
ones
queued
up
and
there
have
to
be
a
process
assigned
to
that
and
most
important.
We
need
to
document
shepard.
We
need
a
volunteer.
I
B
E
M
James
yeah,
I
have
two
items
of
feedback.
One
is
associated
with
the
choice
of
the
data
elements,
since
I'm
seeing
new
elements
that
I'm
unfamiliar
with
that
are
tbd,
and
I
really
don't
see
a
large
set
of
data
elements
that
exist
in
other
rcs
related
to
registration
data
like
the
data
escrow
rfc.
So
it
may
be
worthwhile
to
review
those
rfcs
and
try
to
pull
in
data
elements
that
are
applicable
a
second
item,
and
I
I
believe
this
also
applies.
M
This
is
what
I
was
trying
to
say
for
the
report
draft
is
making
sure
that
the
data
elements
follow
a
consistent
naming
convention.
I'm
seeing
a
mix
of
abbreviations
versus
bars,
uppercase
versus
lowercase.
I
believe
it
would
be
good
to
formally
define
the
the
convention
and
to
follow
it
consistently
in
the
draft.
I
It's
certainly
data
elements
that
are
defined
in
various
rfcs
we
ought
to
include.
There
will
be
other
data
elements
that
are
coming
up
in
some
of
the
work,
we're
doing
and
other
people's
works.
That
will
not
be
familiar
to
everybody,
which
is
at
least
in
part
part
of
the
motivation
for
this,
but
with
respect
to
covering
those
things
that
have
been
used
in
other
documents,
that's
an
extremely
good
suggestion
and
on
your
other
suggestion
of
using
consistent
naming
and
naming
convention
is,
is
also
quite
appropriate.
H
Yeah,
can
you
hear
me
yeah
wonderful
things,
so
I
have
two
general
opponents.
One
is
I
mean
as
most
of
the
participants
in
this
group
at
some
point
in
our
careers
we
have
to
implement
a
registry
or
registration,
and
over
time
I
learned
that
I
mean
there
are
going
to
be
conflicts
because
the
risk
is
going
to
be
dynamic,
obviously,
and
then
the
contracts,
local
law.
All
of
these
things
are
also
dynamic.
H
So
I
was
wondering
if
that
draft
should
say
something
like
if
there
are
some
conflicts
between
definitions
between
local
law
contracts
or
policy
and
draft
and
the
dictionary
itself,
you
need
to
go
on
and
look
for
your
own,
like
legal
advisor
for
any
kind
of
help.
I
mean
I
learned
over
my
career
that
when
there
are
conflicts
I
should
try
to
go
and
look
to
the
legal
advisor
of
the
company
to
understand
what
should
I
do
right.
H
So
it's
kind
of
a
suggestion,
just
maybe
say
there
that
that
is
hey
guys
if
you
find
in
conflicts,
go
on
and
find
some
kind
of
legal
advice
or
something
like
that,
and
the
second
comment
is:
I
think
that
the
draft
mentions
there
are
2.1
once
the
registry
is
available,
the
definitions
could
change
right.
O
H
I
H
I
Are
yeah
very
interesting?
Are
you
suggesting
that
the
registry
should
contain
the
history
of
the
definitions,
even
if
they've
changed
over
time.
H
Yes,
I
I
think,
that's
that's
why
what
it's
suggesting,
because
normally
when
you
go
to
an
register,
you
can
see
like
the
current
version
right
that
you
don't
have
like
a
version
I
mean
usually
right.
I
don't
know
if,
in
the
general
street
we
have
an
example
of
array
history
with
versioning,
but
some
kind
of
version
it
should
be,
should
be
there
or
notes,
or
something
that
says
this
change
from
this
to
this.
At
this
point
in
time,.
I
Yeah,
I
understand
what
you're
saying
I
don't
have
any
direct
experience
with
that
in
this
context,
are
there
people
is
this
come
up
in
other
situations
where
an
iana
registry
has
revision
history
as
part
of
the
registry.
B
B
Otherwise,
I
cannot
open
the
tube
right,
jim
you're,
in
the
queue
as
well
making
a
comment
about
this.
A
Yeah,
you
know
I
I
I
think
you
know
in
my
mind,
as
I
think
about
this,
for
this
document.
A
I
don't
know
the
answer
specifically
to
what
ayanna
does
I'm
not
aware
personally
of
any
history
being
maintained,
and
I
am
a
registry,
but
I
wouldn't
consider
myself
an
expert
there's
just
way
too
much
going
on
there.
So
that's
a
question
that
we
could
certainly
ask
if
we
think
it's
useful.
A
What
does
occur
to
me,
though,
is
that
there
was
a
question
earlier
and
I'm
sorry
I
I
forget
who
asked
the
question.
Oh
michelle
is
here
and
she's,
saying
in
the
chat
room
that
there
are
examples
of
versioning
within
ayanna
registries.
A
Not
many,
but
she
recalls
a
few
she'll
have
to
find
some
examples
for
us
she's
offering
to
do
that,
which
is
very
kind.
So
thank
you
michelle
for
that.
But
the
other
thing
that
occurs
to
me
is
there's
a
question
earlier
steve.
I'm
sorry
I
forget
who
asked
the
question
but
a
a
comment
about
whether
or
not
there's
any
concern
about
you
know,
contracts
and
regulations
and
laws
that
might
impact
what
a
an
element
looks
like,
and
there
was
a
related
question
about.
A
Should
we
care
more
about
the
semantics
or
the
syntax
of
the
element
seems
to
me
this
fits
into
the
same
category.
Maybe
it's
appropriate
to
take
a
little
bit
of
a
step
back
here
and
just
think
about
where
we're
trying
to
go
with
this
document.
I
shouldn't
say
we
at
the
working
group.
You
know
you
where
you
want
to
go
with
this
document
and
and
and
what
you
want
to
do
there.
I
I
don't
know
if
that's
that's,
that's
a
proper
thing
to
do
so.
I
Yeah,
thank
you.
Well,
the
devil's
always
in
the
details,
general
attitude
here
is
that
we're
not
trying
to
solve
conflicts
so
much
as
provide
common
terminology
where
common
terminology
is
sensible
and
then,
if
there
are
issues
about
how
it
gets
used
or
what
it
means
or
something
that
those
get
pushed
up
a
level
into
the
proper
venues.
But
not
this
one,
and
this
this
is
intended
to
sit
underneath.
If
you
will
any
debates
about
policy
related
things
or
legal
issues,
but
inevitably
I
can.
I
I
can
envision
situations
where
the
mere
fact
of
trying
to
make
the
separation
between
what
is
commonly
understood
and
aware
of
the
local
interpretations
could
lead
to
some
interesting
things,
for
example,
and
I'm
just
making
this
up
as
I
go
here
pretty
much
that
if
we
ask
if
we
have,
there
was
a
reference
to
a
data
element
that
defines
whether
or
not
the
the
registration
is
for
a
legal
person
or
for
a
natural
person.
I
B
P
P
K
I
do
I
think
I
muted
myself.
Can
you
hear
me
yeah
perfect,
thank
you,
so
I
have
to
put
on
my
my
hat
as
representing
registrars
inside
the
icann
world.
Despite
my
personal
opinions
about
this,
I
think
is
a
good
idea.
K
There
are
some
concerns
about
some
of
the
fields
being
collected
or
how
they're
defined
for
the
registrar
information
and
the
the
hope
was
one
that
registrars
there's
a
lot
of
variation
in
what
information
may
or
may
not
be
collected
at
registrars
based
upon
their
business
model
and
the
presence
of
fields
may
beg
the
question
among
those
who
are
data
collectors
as
to
why
something
maybe
is
or
is
not
there
among
those
who
might
request
data,
that
is
where
they're
seeking
to
get
all
the
data
they
possibly
can,
and
I
think
there's
some
some
time
and
thought
needs
to
be
put
into
what
what
fields
maybe
should
or
shouldn't
be
there
and
and
I'm
just
that's
a
collection
of
feedback
from
among
registrars
and
again,
I'm
I'm
stating
that
out
of
responsibility,
despite
maybe
my
personal
feelings
on
that.
B
Q
Hi
this
is
jasdeep
singh
erin.
So
one
suggestion
this
is
for
steve
and
heather.
B
Thank
you,
justin
steve
one
closing
remark
five
seconds.
B
Thank
you
and
we
need
a
document
shepard
yeah,
okay,
thank
you.
Then
we
will
move
on
with
the
agenda
and
we
have
one
more
presentation
which
is
new
work.
Jim,
can
you
bring
up
the
slides
and
it's
mario
who's
going
to
present
something
about
epp
over
http
yeah?
But
I
I
don't
know.
B
So,
are
you
saying
don't
do
your
presentation
but
have
james's
comment?
No
jim
james
said
you
go
ahead.
Mario.
G
Okay:
okay,
no
problem:
this
is
a
presentation
about
the
recent
document
we
have
submitted
as
a
joint
proposal
by
dot
it
and
dot.
Pl
a
few
introductory
words
about
this
document.
G
It
doesn't
aim
to
be
a
revolutionary
proposal.
Just
aims
to
define
the
rules
for
implementing
app
over
http
next
slide.
Please
what
what
could
be
the
motivation
of
implementing
fbp
over
http
http
is,
as
is
loosely
coupled
with
the
network,
so
you
don't
have
to
deal
with
all
the
low
level
details
typical
of
tcp
programming.
G
It
provides
a
well-known
current
server
communication
model
that
is
supported
by
largely
by
all
the
platform
software
platform
available
it.
It's
simple
to
its
simplicity,
reduces
the
development
time
and
it
must
be
noted
that
most
of
the
burden
of
handling
the
connection
this
the
http
session
and
the
request
and
the
responses
is
normally
done
by
a
an
application
server.
G
The
with
regard
to
this
gap,
the
speed
gap
between
http
and
tcp
http
has
become
faster
version
vibration,
and
now
we
can
say
that
that
gap
is
not
so
large.
As
in
the
past
about
load
balancing,
we
can
say
that
load
balancing
can
be
more
easily
implemented
at
lawyer,
7,
that
at
lawyer
4,
because
most
of
the
load
balancer,
our
software
are
instead
load.
Balancer
at
lawyer,
4
are
more
dependent
on
the
hardware
and,
as
correctly
pointed
out
by
gavin
in
his
feedback
on
the
my
little
list.
G
If
the
migration
to
cloud
is
the
future
migrating,
an
http
server
to
cloud
requirements,
effort
then
at
ntcp
server
next
slide,
please
so
how
app
messages
are
exchanged
in
this
proposal.
The
client
must
use
the
http
post
method,
tuition,
epp
command
and
the
server
receiving
a
request
returned
the
ppms,
the
pp
response
in
the
response
body
setting
the
content
length
either
to
indicate
the
byte
length
of
the
entity
body.
No
message
information
must
be
issued
through
any
other
part
of
of
the
request
or
the
response.
G
G
Server
receiving
an
epp
logging
must
you
common,
must
use
this
set
cookie
responsibility
to
send
a
token,
also
known
as
the
session
id,
that
the
client
will
will
use
to
to
in
the
future
request
in
within
the
scope
of
the
fpp
session.
The
name
of
the
cookie
attribute
is
not
relevant
and
it
depends
on
the
implementation.
G
This
is
an
example
of
a
set
cookie
attribute
setting
the
the
session
id
and
the
use
and
the
client
server
using
this.
The
session
id
in
the
in
the
subsequent
request.
Next
slide.
Please,
the
session
ended
by
the
client
by
submitting
the
the
the
app
logout
command.
G
G
Next
slide,
please,
the
command
does
not
is
the
only
common
that
can
be
issued
outside
in
a
pc
an
epp
session
together,
we
obviously
with
the
people
login
to
start
the
session.
In
such
a
case,
the
service
must
return
the
greatest
response
without
starting
a
session.
G
Obviously,
a
client
may
issue
the
the
low
command
within
an
ep
session,
for
example,
to
keep
it
alive
next
slide,
please
just
to
emphasize
the
clear
distinction
between
the
application
lawyer
and
the
transport
lawyer
there.
There
is
no
mix
between
the
return
codes
provided
by
http
and
epp,
so
each
http
error
codes
must
be
used
for
signaling.
G
Only
http
request,
failure
and
app
error
codes
must
be
used
for
signaling
app
common
failure.
So
this
means
that
the
http
retro
code
200
is
used
for
both
successful
and
successful
epp
requests
next
slide.
Please
we
have
one
more
minute:
mario
okay,
we
have
two
implementation.
They
are
stable.
They
are
live
implementation.
They
are.
They
have
been
working
for
many
years
in
more
than
a
decade.
G
G
Next
slide,
please
the
final,
and
there
are
some
other
possible
additional
security
measures
to
protect,
to
prevent
the
session
id
to
be
from
being
ejected
and
a
service
are
finally
recommended
to
control
the
number
of
simultaneous
open,
ep
session
and
http
connection
to
mitigate
the
risk
of
resource
starvation.
G
Okay,
thank
you.
Mario,
we
are
waiting.
The
final
note,
sorry,
is
that
the
authors
would
like
to
would
like
to
ask
the
working
group
to
consider
this
document
for
that
option.
O
O
I
want
to
say
that
the
document
should
reference
the
for
the
security
considerations
from
the
security
working
group
about
which
tls
version
to
use
and
which
tls,
ciphers
and
and
so
on,
because
that
I
think,
is
not
an
expertise
of
our
working
group
and
lastly,
I
have
the
reference
http
3
in
the
document,
but
http
3
allows
you
to
basically
have
several
sessions
inside
the
same
connection
and
something
of
that
mapping
would
at
least
been
talked
about
in
the
document.
B
Okay,
thank
you.
Gavin.
R
Yeah,
thank
you.
Kevin
brown,
centronic.
All
right
already
said
what
I
said
wanted
to
say
about
http
3's
streams,
but
I
did
want
to
note
in
security
considerations.
It
makes
the
the
the
draft
makes
ip
based
access
control,
a
mutual
tls
optional,
which
is
a
regression
from
the
the
current
specification
for
a
bpp
over
tcp
or
opp
over
tls,
where
they
are
mandatory.
S
Thank
you
antoine
the
far
too
many
gems
in
this
working
group.
My
name
is
jim
reed,
I'm
just
violently
opposed
to
cookies
in
any
possible
shape
or
form.
I
just
don't
like
them,
and
I
don't
understand
why
you
would
need
to
complicate
the
session
for
an
app
with
having
cookies
in
there
and
deal
with
the
issues
of
stale,
cookies
and
refreshing
cookies
and
all
that
stuff.
Why
not
just
to
limit
that?
What
benefit
do
we
get
for
an
epp
session
that
has
cookies?
G
We
decided
the
title
of
the
document
that
is
compliant
to
the
the
name
of
rfc
57
34,
so
the
name
of
that
document
is
app
over
tcp,
no,
not
over
tls.
So
in
the
same
way,
I
I
I
I
entitled
the
the
document
app
over
app
over
http
and
on
and
not
or
app
over
https,
but
in
the
document
is
stated
that
tls
is
required,
so
why
we
use
the
cookies,
because
we
adopt
a
standardized
method
to
map
a
an
applicative,
an
application,
an
application
session
to
a
an
http
session.
G
Libraries
supporting
http
requests
and
responses
and
sessions
are
accustomed
to
to
to
manage,
so
you
don't
need
to
make
to
to
implement
nothing
party,
nothing
special,
because
you
you
need
only
for
for
the
client,
for
example,
to
enable
cookies
management
and
that's
it.
So
I
I
think
that
this
is
a
a
a
simple
way
to
to
to
manage
a
session
for
for,
for
an
fpp
client.
B
B
Yeah
and
with
that
we
come
to
the
end
of
our
agenda
if
there
are
no
any
other
business.
This
is
a
last
call
for
any
other
business.
If
we
can
do
it
in
one
minute,.
B
And
I
don't
see
any
hands
and
with
that
I
think
we
ran
a
little
bit
over
time.
That
was
not
expected,
but
it
was
a
good
session,
see
you
all
on
the
mailing
list
and
let's
continue
the
discussions
there
and
with
that
I
adjourned
this
meeting.
Thank
you
all
and
thank
you
for
who
was
taking
the
minute
jim.