►
From YouTube: IETF102-REGEXT-20180717-1330
Description
REGEXT meeting session at IETF102
2018/07/17 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
So
with
that,
this
is
the
note.
Well,
you
know.
Hopefully
you
have
seen
this
many
times
here,
but
it
is
important
to
put
it
up
in
front
of
everything
you
know
there
are.
There
are
a
number
of
things
that
are
touched
on
here,
not
just
what
it
means
to
make
a
public
contribution
and
the
fact
that
that
can
be
used
by
the
IETF
and
IETF
process,
but
there's
a
code
of
conduct
in
here.
A
You
know
issues
about
the
process,
expectations
on
people
and,
of
course,
our
privacy
policy,
and
so
please,
if
you
have
not,
you
know,
please
make
sure
to
take
the
time
to
review
that
material
so
that
you
know
we
can
all
be
working
together
as
a
team
here
to
make
the
internet
a
better
place
right.
Oh
I
probably
should
have
started
off
by
saying
also
that
I
am
James
Galvin.
One
of
the
co-chairs,
Antoine
de
Sean,
is
with
us
in
the
me
deco
up
there
at
the
top.
He
is
the
other
co-chair.
A
We
were
doing
the
sound
check
with
him
just
a
minute
ago,
so
that
we
we
know
that
it
all
works,
and
so
with
that
this
is
a
document
review,
request,
I've,
always
kind
of
put
this
up
here.
This
is
just
something
we've
been
been
doing
here
in
this
group:
we're
a
relatively
small
group
and
a
small
group
of
people.
You
know
self-selected
and
we
we
have
actually
been
been
having
some
issues
trying
to
keep
up
with
document
shepherds
and-
and
you
know,
moving
documents
along
and
so
I
just
think.
A
You
know
in
the
IETF
context
and
journal
it's
useful
to
keep
in
mind
that
you
know
the
ITF
is
larger
than
just
this
working
group.
So,
in
addition
to
please
paying
attention
to
documents
in
your
working
group
and
taking
the
time
to
comment
and
actually
read
them
and
support
them
work
or
not,
as
the
case
may
be
now,
please
do
reach
out
and
take
a
look
at
documents
in
other
working
groups
and
equally
feel
free
to
ask
others
to
come
and
look
at
your
documents.
A
We
have
had
two
meetings
here
at
this
IEF
session.
One
session
two.
This
is
our
normal,
regular
working
group
meeting.
We
had
a
work
session
yesterday
for
a
couple
hours
and
we'll
get
a
brief
summary
of
each
of
the
documents
that
was
talked
about
at
that
session.
So
let's
jump
right
in
here
to
our
agenda
and
formally
start
the
meeting
as
usual.
We
need
our
jabber
and
note
scribe
and
look
around
can
I
get
any
volunteers
to
do,
jabber
and
and
notes
for
us,
please
somebody.
Oh
it's
not
usually
this
hard,
but.
A
Okay,
fair
enough
I
was
trying
to
expand
the
slide
to
be
itself
on
the
full
screen,
but
you're
right,
okay,
so
that's
better!
That's
fine,
really
I
know
that
we
usually
I,
don't
really
want
to
reach
out
and
tag
somebody
to
get
the
regular
people,
but
we
really
do
need
a
jabber
scribe
and
somebody
just
to
take
notes.
A
You'll
do
the
dad
sorry
you're
sitting
in
the
seat
that
should
have
assigned
it
to
you,
because
you
were
sitting
there.
That's
right
thanks,
Wendy
somebody
to
take
some
notes
for
us.
Please
I'll!
Look
in
that
yeah!
It's
a
short
meeting!
Guys
really
could
use
somebody
just
to
take
some
notes.
You
know
just
a
quick
summary
of
actions
grab
the
agenda
and
if
we
make
any
comments
about
anything,
really,
okay,
Breck.
Thank
you
very
much
appreciate
it.
Rick
Wilhelm,
okay,
we've
already
done
the
note.
Well,
so,
let's
jump
right
into
the
Charter
update.
A
This
slide
actually
shows
on
it.
The
change
in
the
Charter
that
has
been
put
on
the
mailing
list,
we've
gone
through
working
group
last
call
and
it
has
been
submitted
to
our
area
director.
The
last
two
paragraphs
under
the
old
were
replaced
by
the
one
sentence
there
that
you
see
under
new
for
those
who
haven't
seen
that
before
there
were
a
couple
of
issues
that
were
talked
about
on
the
mailing
list.
A
With
respect
to
this,
you
know
people
in
general
were
we're
worried
about
this
group
having
too
broad
a
scope,
and
you
know
likely
to
take
on
more
things,
and
it
really
can
do
and
the
response
you
know.
The
explanation
that
had
given
on
the
mailing
list
and
I'll
just
highlight
here
is
there
is
that
key?
You
know
phrase
there
in
the
middle
of
the
sentence
at
the
bottom,
in
consultation
with
its
responsible
area
director.
A
So
the
idea
here
is
to
try
not
to
add
too
many
words
to
finding
exactly
what
we
may
or
may
not
do.
We
do
want
to
try
to
use
the
phrase
you
know
related
to
the
operation
of
internet
identifier,
registries,
whatever
those
might
do
we're
believing
that
that
includes
both
our
DAP
and
EPP,
and
it
allows
us
to
to
get
into
some
of
the
operations
and
and
standardizing
certain
activities
that
those
registries
would
take
on
and,
of
course,
we
would
always
have
to
make
that
with
the
responsible
area
director.
A
So
the
escape
clause,
if
you
will
is
the
area
director,
has
to
agree.
So
we
always
have
an
opportunity
to
make
sure
that
we
don't
have
a
lot
of
scope,
creeks
and
doesn't
just
slip
in
because
we
want
it.
Okay,
I'm
told
by
the
area
director
that
our
Charter
is
on
the
nextel,
a
chat
and
he's
oh
I'll.
Let
him
speak
for
himself.
A
B
A
Okay,
thank
you
apologize
for
that
confusing,
but
that
should
you
know
the
expectation
is
that
if
all
of
that
proceeds
without
incident,
then
we'll
be
well
prepared
to
pick
up
some
of
the
new
work
items
that
we
have
pending
in
our
queue.
Okay
document
management:
this
is
just
another
opportunity
for
Antoine
and
I
just
to
reach
out
and
appeal
to
people.
You
know
please
to
help
us
out
with
respect
to
document
Shepard.
A
We
actually
have
a
couple
of
documents
that
are
pending
a
document
Shepard
right
now
and
I
know
that
it
is,
if
you
use
a
process,
if
there's
really
just
a
form
that
you
fill
out
and
then
you
have
to
manage
all
the
comments
that
the
isg
produces
as
they
react
to
the
document
once
it's
submitted
in.
We
look
for
the
document,
shepard
commandments,
that
the
important
thing
is
the
document.
Shepard
cannot
be
a
current
document
author
or
editor,
so
you
you
need
a
someone,
that's
independent
from
all
of
that
and
I
don't
know
Antoine.
A
Okay,
so
we'll
move
on
then
to
existing
document
status.
We
have
lots
of
document
status.
This
time,
I
think
that
this
three
month
period
has
probably
been
one
of
our
most
productive.
Here,
a
lot
of
things
can
go
come
to
conclusion.
So
that's
been
a
good
thing,
so
we're
gonna
go
through
four
categories
of
things
here
in
terms
of
items
in
iesg
last
call,
the
top
two
are
actually
in
is
G
last
call
there
are
there
in
the
is
G
queue
and
they're.
Just
waiting
to
come
out
to
Adam
wants
to
step
up.
B
A
Good,
thank
you.
So
these
documents
move
along
most
important
here,
is
that
they're
kind
of
out
of
our
queue.
That's
what
got
them
onto
this
slide.
Labeled
IETF
last
call
there.
They
are
off
of
our
list,
which
means
the
milestones
list
has
already
been
updated
too,
so
they
don't
have
them
the
last
to
the
organizational
mapping
and
the
and
the
the
epp
extension
for
the
organization
so
down
here
in
italics.
A
I
put
them
on
this
slide
because
they've
been
submitted
to
the
isg,
but
they
they
haven't
moved
further
than
having
been
handed
to
the
area
director
for
the
next
step
in
the
process,
but
they
having
done
that
they
get
to
get
off
of
our
milestone
list
and
so
they've
been
adjusted
in
that
way.
Okay,
I'm
gonna
along
through
these,
except
for
a
couple
that
I
know
we
need
to
talk
about
unless
someone
wants
to
jump
up
at
the
mic
and
we
can
go
back
if
I
move
past
something
that
you
wanted.
A
Documents
that
are
past
working
group
last
call
but
have
not
actually
been
submitted
up.
So
the
first
one
up
here
is
the
bunting
registration.
It's
it's
targeted
for
being
submitted
for
an
informational
document,
it's
the
one
which
is
pending
a
document
Shepard.
So
we
really
are
very
interested
in
someone
who's
willing
to
step
up
and
help
us
along
here
and
and
be
the
document
Shepherd
for
this
and
just
move
this
document
along.
A
If
anyone
is
interested
in
doing
that,
certainly
appreciate
your
you
know,
raising
your
hand
or
saying
so
on
the
mailing
list
or
please
come
up
and
see
me
at
the
end
of
this
meeting.
The
changeful
document
is
just
waiting
for
its
document
shepherd
right
up
and
the
last
one
is
the
registry
fee,
extension
and
I
think
we'll.
It
is
past
working
group
last
call,
but
a
technical
issue
came
up
when
the
document
shepherd
was
doing
there
right
up
and
which
one
of
you
is
gonna
end
up.
You're
gonna
do
that
James?
C
D
So
group
of
us
met
earlier
today
and
there
was
a
group
from
Verisign
from
affiliates
from
GoDaddy
and
there
was
also
Patrick
on
the
remotely
logged
in.
So
what
we
did
was
we
discussed
the
particular
topic
of
the
standard
attribute
and
in
during
the
review
of
the
mailing
list,
identified
the
specific
comments
on
the
list
and
why
don't
when
I
was
going
through
the
review
it
looked
like
there
was
not
a
consensus
at
the
time.
So
that's
why
I
brought
it
up.
D
We
discussed
it,
and
the
result
of
this
was
the
fact
that
we
felt
like
it
was
in
line
with
the
data
model
of
of
the
system
and
in
in
line
with
the
protocol
itself,
and
that
adding
this
attribute
really
didn't
fundamentally
change
the
behavior
at
all.
So
the
recommendation
at
this
point
was
to
move
the
standard
attribute
from
the
command,
which
was
incorrect
to
the
response,
as
as
I
was
doing
the
review
it's
identified,
it
was
actually
in
the
wrong
place.
So
we
need
to
fix
that.
A
Okay
and
what
will
happen
there
is
we'll
end
up
with
version
12
I,
think
of
that
draft
at
that
time,
and
we
will
essentially
immediately
well
as
soon
as
the
write-up
is
finished,
then
we'll
just
immediately
submit
that
to
the
isg
to
move
that
along.
This
has
been
one
of
our
most
dramatic
documents.
We've
spent
probably
far
more
technical
time
on
this
document
than
many
others,
so
I
think
it's
quite
a
milestone
in
our
work
products
here
to
move
this
document
along.
Please.
E
Given
that
this
decision
is
just
going
to
be
described
to
the
mailing
list,
it
is
possible
that
someone
on
the
list
may
object,
may
suggest
an
alternative
and
so
I
think
we
do
need
a
little
bit
of
time
to
ensure
that
we
we
have
consensus
on
the
approach
and
you
know
that
it
doesn't
warrant.
You
know
either
continued
discussion
or
another
working
group
last
call
or
something
right.
E
A
Yeah
I
see
that's
my
co-chair,
saying
that
my
co-chair
no
I
may
need
to
sync
up
a
little
bit
here,
but
you
know
fair
point:
Scott
and
I
didn't
mean
to
to
extend
beyond
that
implicit
and
let
me
just
make
it
so
everyone's
clear
we're
not
trying
to
overtake
the
the
discussion,
but
the
consent.
The
what
we
decided
in
our
discussions
today
is.
We
are
trying
to
figure
out
whether
this
was
a
technical
error
in
the
specification.
A
You
know
in
an
oversight
at
some
point
in
time
that
we
missed,
and
in
any
case
you
know,
as
always
with
in
the
ITF.
You
know
all
final
decisions
are
made
on
the
mailing
list,
so
there's
always
that
possibility
and
in
particular
Pat
Maroni,
although
we
did
our
best
to
represent
and
talk
about
his
position
in
all
of
this,
you
know
in
fairness.
He
was
not
part
of
the
discussion
this
morning
open.
We
were
trying
to
figure
out
what
to
do.
A
We
do
think
that
we
we
have
a
decision
and
a
choice
which
which
meets
everyone's
needs
and
also
honors
and
and
respects
the
protocol,
as
it
should
be,
so
we're
not
making
a
technical
change.
We
had
an
oversight
in
not
having
completed
a
change
to
the
schema
when
we
had
a
discussion,
you
know
seven
months
ago
and
it
got
into
the
document,
and
it
was
until
the
document
shepard
was
doing
there
particularly
thorough
review
in
this
case
that
they
identified
what
was
going
on,
but
as
in
in
fairness,
you're
right.
A
We
will
post
all
of
this
on
the
mailing
list
and
make
it
clear
what
happened.
This,
of
course,
will
be
documented
in
an
in
a
proper
way
by
the
document
shepard
when
we
go
to
submit
the
document
up
and
we'll
allow
some
time
for
discussion
on
the
mailing
list.
Just
in
case
somebody
wants
to
bring
something
up
that
we
might
have
missed,
but
ideally
they're.
You
know
we're
hoping
that
there
won't
be
any
issue
there.
A
We've
tried
to
cover
all
of
the
issues
that
we
knew
about
and
all
the
questions
that
we
had
so,
but
thank
you
for
that.
Okay
moving
along
quickly
again
here,
so
there
are
other
documents
that
are
listed
on
our
vert
on
our.
We
have
other
documents
listed
in
our
working
group
list
of
documents,
and
there
are
two
other
documents
which
are
still
on
our
milestones
list
that
I
want
to
call
out
that
we
need
to
make
reference
to
here.
Okay,
so
the
ones
in
italics
here
on
this.
A
The
second
and
the
fourth
one
are
actually
not
on
the
milestone
list.
They
are
documents
that
are
still
in
the
working
group
that
we
have
not
progressed
and
have
not
moved
forward
now
a
case
of
the
TM
CH
functional
specification
that
has
a
technical
issue
on
on
the
ICANN
side
that
we're
waiting
to
be
resolved.
A
So
that
document
is
officially
parked
for
right
now,
and
you
know
we're
hoping
that
we're
going
to
get
some
resolution
on
the
other
side
so
that
we
can
incorporate
that
into
this
document
and
then
and
then
move
that
one
along
the
verification
code.
Extension
we've
just
kind
of
ignored
for
a
while.
We
haven't
tried
to
progress
that
or
move
it
forward
so
and
we
have
not
actually
even
proposed
a
timeframe
for
when
we
want
to
pick
that
up.
A
A
We
have
actually
had
some
discussion
about
those,
but
we
we
have
not
chosen
to
to
pick
those
to
move
along
I
know
the
editors
of
the
DNS
operator
document
really
do
want
to
move
that
document
along.
They
have
some
issues
to
address
and
they
need
to
revive
that
document
and
revise
it
and
then
put
it
back
up
on
our
priority
list
so
that
we
can
close
on
that
document.
The
the
validate
document
and
I'm
thinking
I'm
drawing
a
blank
here,
I'm,
actually
forgetting
now
after
having
put
all
this
together,
yes
Roger.
F
Actually,
this
Roger
Carney,
we
met
and
I
say
a
month
ago,
I
can't
remember
exactly
I
had
an
interim
meeting
and
we
were
going
to
cover
the
validate
and
the
registry
mapping,
but
we
got
stuck
on
the
validate,
so
it
was
actually
a
very
productive
meeting.
We
do
have
quite
a
few
changes
coming
out
of
that
and
there's
been
some
I'll
say
very
few
suggestions
on
lists
so
far
since
the
meeting,
but
we
do
have
a
handful
I
would
say,
probably
six
fairly
good
modifications
to
it
that
are
coming
in
the
next
few
weeks.
A
Good,
so
work
is
progressing
there.
So
that's
a
good
thing.
Okay,
all
right!
Moving
on
new
work
items
we
have,
we
had
multiple
presentations
over.
You
know
the
couple
of
years
that
we've
been
in
existence
about
potential
work
items.
These
are
three
that
stand
out
right
now
as
being
recently
proposed
and
they
seem
to
have
more
energy.
So
this
is
not
necessarily
intended
to
be
an
exhaustive
list
of
things
that
might
come
to
us,
but
I
wanted
to
highlight
them
and
make
them
visible
for
new
work
items
and
I
guess
James.
A
D
And
there
we
go
okay,
great
all
right,
so
yeah
I
posted
this
extension
recently
and
there's
been
some
dialogue
on
the
list,
so
I
wanna
go
to
the
next
slide.
Yes,
so
the
problem
is
that
this
particular
extension
dress
is:
is
first
off
extending
the
maximum
password
length
past
16
characters
which
is
in
the
RFC
today.
The
second
problem
is
the
fact
that
there's
no
capability
in
EBP
today
to
return
back
errors
and
warning
security
Arizonians
to
the
client
examples
include
passwords
pirates
or
tippet
expiry,
insecure
ciphers
or
TLS
protocols.
D
D
The
next
slide,
please,
so
I
cover
each
of
the
problem,
so
the
first
one
is
to
extend
the
password
past
16
characters.
The
way
this
works
is
that
it
extends
the
login
command.
Since
the
RFC
requires
a
password
of
six
to
sixteen
characters,
a
constant
value
is
used
there.
In
essence,
in
brackets,
login
security
and
that
informs
the
server
to
look
into
the
extension
and
in
essence
the
client
continue
to
use
passwords
as
they
do
today.
So
it's
forward,
I
guess
is
backward
compatible
and
then
the
logging
extension
will
allow
for
passwords
beyond
16
characters.
D
So
what
happens
is
that
the
new
elements
in
the
extension
will
support
a
minimum
length
of
6
which
matches
what's
in
the
RC
and
it
has
an
undefined
maximum
so
that
we
could
have
it
move
forward
as
curing
standards
change
in
the
next
slide
and
here's
an
example
very
straight
forward.
So
in
essence,
you
can
see
here
that
the
constants
are
in
the
the
base
and
then
that's
telling
the
server
to
look
in
the
extension
and
there's
a
longer
password.
It's
very
straightforward.
D
The
next
one
is
a
little
bit
more
complex
but
very
useful.
In
essence,
the
the
server
will
be
able
to
return
back
security
events
and
it
could
be
a
list
of
them
to
the
client
and
the
only
time
this
extension
is
included
is
first
off
the
unhandled
namespace
issue.
If
the
client
includes
it
that
extension
and
login
services-
and
there
was
at
least
one
event-
so
go
to
the
next
slide,
so
these
are
the
attributes
of
the
security
events
you
have
a
type
and
there's
a
set
of
predefined
weathers
paths
or
certificates.
D
D
You
can
have
an
expiration
date
for
things
like
password,
expires
or
expiry,
and
there
were
some
additional
attributes
here
for
statistics
which
would
be
a
value
in
duration
and
there's
a
free-form
description
for
the
next
one
and
we'll
see
an
example.
There's
an
example
of
a
password
that
is
going
to
expire.
So,
in
essence,
is
a
warning.
The
the
authentication
in
fact
worked,
but
this
provides
the
client
with
information
that
they
need
to
change
the
password
next.
D
Here's
an
example
of
a
scenario
where
the
password
has
expired.
So
therefore
it's
an
authentication
error.
The
reason
why
it's
an
error
is
because
the
passwords
in
fact
expired,
keep
going
ok
and
then
we
have
the
user
agent
information.
I
gotta
tell
you
it's
very
difficult
on
the
server
to
identify
what
clients
will
be
impacted
by
certain
things.
So
without
having
the
user
agent
information,
we
can't
you
can't
make
those
calls,
so
this
extension
will
allow
for
the
client
to
include
the
user
agent
information
in
the
login
command
itself,
so
move
the
next
line.
D
Here's
an
example
of
it.
So
in
essence,
in
the
extension
it
just
has
the
user
agent
information
includes
it's
an
SDK
use
and
Java
on
the
Mac
and
that's
pretty
much
it.
So
we
did
have
some
feedback
on
the
list.
Some
of
those
folks
really
wanted
to
broaden
this
to
consider
other
authentication
methods
right
now.
It's
it's
very
limited,
so
I'll
be
looking
for
any
suggestions
about
how
to
specifically
do
that.
If
that
is
the
case,
there's
comments
around
the
use
of
the
constant
value.
D
So
in
conclusion,
this
extension
solves
the
three
problems
by
extending
the
login
command
to
address
the
password
length
address
the
user
agents
and
in
the
response,
will
provide
back
the
security
warnings
and
errors.
So
I
highly
suggest
that
you
go
ahead
and
review
it
and
provide
any
feedback.
All
feedback
is
welcome.
C
G
G
A
D
D
A
Okay
and
we
heard
perfect
from
Alexander,
so
that's
perfect,
okay,
all
right
good!
Thank
you,
James
and
going
on
I
think!
That's
it
for
those.
So
before
we
move
into
the
other
thing,
I
want
to
talk
a
little
bit
about
next
steps.
I
just
realized
I,
didn't
we
didn't
put
a
slot
on
here
for
talking
about.
A
What's
what's
happening
next,
what
we
have
been
focused
on
quite
dramatically
this
year,
in
particular
over
the
last
12
months
since
last
summer,
and
been
especially
successful
in
closing
the
loop
here
on
a
number
of
things
is
to
clear
our
milestone
list
and
in
the
number
of
documents
that
we
have
on
our
docket.
We've
been
kind
of
moving
things
along
kind
of
slowly
and
it's
been
really
helpful
to
to
suddenly
come
to
closure
on
a
number
of
things
and
and
really
close
that
loop
recently.
A
A
And
you
know
we're
gonna
have
and
we
have
some
new
work
items
here.
I
just
feel
like
we
didn't
there's
a
workout
I
mean
we
didn't.
We
didn't
talk
about,
did
I
yeah
I
skipped
over
the
escrow
stuff.
Didn't
I
I
went
right
past
that
okay,
we'll
come
back
to
that
in
a
moment,
and
we
have
the
escrow
stuff
will
give
Gustavo
chance
to
come
back
and
remind
us
of
that
and
and
speak
to
that
stuff
too.
So
we
have
a
number
of
pending.
A
Things
have
been
out
there
and
we
will
try
to
move
these
along
in
the
mailing
list.
The
critical
thing
at
the
moment
is
to
continue
to
complete
the
couple
of
documents
that
are,
you
know
very
close
and
all
but
published.
We
have
a
number
that
are
right
there
and
we're
just
going
to
about
done
with
that.
We
also
need
our
Charter
update,
so
we
need
to
get
past
that
with
the
isg
and
our
air,
a
director,
and
hopefully
that
will
be
successful.
A
So
I
suspect
that
leading
in
to
the
next
IETF
meeting,
we
will
have
opportunities
on
the
mailing
list
and
we'll
be
reaching
out
to
talk
about
working
from
adoption
on
some
new
work
items
and
we'll
need
to
prioritize
them
in
an
upper
State
update
our
milestone
list.
Accordingly.
Okay,
so
we've
been
doing
a
good
job
here
lately
of
getting
things
off
our
miles
to
enlist.
It
is
now
down
to
just
having
the
couple
of
things
open
that
we've
already
reviewed
and
I
mentioned.
A
Everything
else
has
been
shuttled
off
and
had
its
state
change
so
that
we
know
where
it
is,
and
that's
been
a
good
thing.
So
I
guess
I
just
wanted
to
call
that
out
for
people
watch
for
some
notes
on
the
list
about
the
Charter
update
the
last
couple
of
documents
to
move
on
and
we'll
start
bringing
some
new
documents
informally
into
the
working
group
and
move
them
along.
So
just
will
and
the
like.
A
C
Once
told
us
on
RIKEN,
so
those
well
of
those
three
documents
in
reality,
the
first
one
was
the
first
version
and
then
it
was
a
split
into
the
other
two.
So
we
can
forget
about
the
fuse
one,
but
the
other
two
are
the
documents
that
I
would
like
in
the
world
to
adopt
at
some
point
in
time.
So
in
the
gTLD
space
we
have
this
process
called
data
escrow.
C
C
A
Elad
speaking
for
myself,
not
as
chair
that
just
emphasize
something
that
Gustavo
had
said,
these
documents
are
pretty
stable.
You
know
most
gTLD
registries
are
already
doing
this
and
they're
using
them.
So
I
would
hope
that
these
documents
probably
represent
a
couple
of
work
items.
We
can
progress
rather
quickly
unless
there's
a
an
issue
which
pops
up
and
now
Rogers
gonna,
tell
me
about
something:
I
missed
right
now.
This
is
Roger
no
I
actually.
F
A
E
Yes,
please
Scott
Hollenbeck
gustaba.
Do
you
know?
Are
these
practices
being
used
outside
of
the
gTLD
space
at
all
and
the
ccTLD
community?
And
here's
where
I'm
coming
with
that
right
in
the
past,
when
we've
looked
at
either
protocols
or
practices
that
are
unique
to
a
particular
community,
a
particular
company,
a
particular
vendor?
The
practice
has
typically
been
to
publish
them
as
informational
right.
E
They
don't
necessarily
represent
a
industry
standard
if
these
practices
were
being
used
in
the
ccTLD
community
as
well,
I'd
feel
much
more
comfortable
with
saying
yeah
I
mean
I,
see
these
as
a
as
a
broad
industry
practice
abroad
in
a
potential
standard
for
the
industry,
but
if
not,
it
might
be
worth
describing
them
as
something
like.
You
know
the
ICANN
recommendation
for
data
escrow,
or
something
like
that.
A
H
Back
here,
Godric
yeah
brick
will
home
there.
We
go
home
bar
sign
the
Rogers
point
about
the
privacy
things
things
for
those
that
don't
lay
low
and
I
can
and
it's
processes
very
often
things
related
to
I
can
to
efforts
to
adopt
the
temporary
specification
and
turn
into
a
more
formal
policy
are
still
very
much
in
flux,
and
it
is
entirely
possible
that
the
escrow
provisions
might
be
changed
by
you
know
because
it's
all
still
unlit
agay
'td
over
the
application
of
the
gdpr
was
just
went
into
effect
on
May
25th.
H
F
Roger
yeah,
so
we
met
yesterday,
we
went
over
the
overview
for
those
that
are
new
to
it,
those
that
ignored
it,
those
that
purposely
forgot
it.
We
still
went
over
the
overview.
We
went
through
all
the
discussion
points
that
came
out
of
the
last
meeting
as
well
as
all
the
discussion
points
on
the
list.
We
talked
through
all
those
things
and
I
know
that
we
have
several
items
that
we'll
be
updating
and
several
other
several
items
that
we
still
need
to
discuss
on
list
prior
to
updating,
but
the
it
was.
F
It
was
a
good
discussion.
Yesterday
we
will
be
trying
to
meet
fairly
regularly
for
the
next
few
months
to
progress
this
along
as
as
quickly
as
we
can
we'll
let
the
list
know
as
soon
as
we
know
anything
about
future
meetings,
but
yeah.
We
do
plan
on
meeting
and
getting
an
update
to
this
rather
soon
so.
A
A
A
F
Has
arm
boarded
a
few
TL
DS
and
if
you
are
on
the
other
side,
if
your
registry,
you
know
how
painful
it
is,
we
send
out
a
30
to
40
page
questionnaire
for
every
TLV
we
on
board.
It
has
300
plus
questions
on
it.
It's
it's
to
answer
all
the
questions
in
the
numerous
RFC's
that
say
may
or
she'll
or
optional,
all
those
things
that
our
registry
gets
a
choice
on
as
a
registrar.
We
need
to
know
what
those
choices
were
so
and
that's
where
the
300
questions
come
from.
F
Naming
every
registry
calls
a
certain
parameter,
a
different
name.
So
even
with
the
300
specific
questions,
we
ask
we
get
back
responses
like
yes
to
something
that
we
were
expecting
text
back
on.
So
it's
one
of
those
things
where
it
typically
can
take
six
weeks
for
us
to
bring
on
somebody
to
answer
all
these
questions.
It's
not
six
weeks
of
work,
but
it's
six
weeks
of
process
time
that
we
had
to
wade
through
the
goal
here
is,
hopefully
we
can
get
80%
of
those
things
done
in
five
minutes.
F
A
D
Yes,
so
just
to
clarify
the
particular
topic
here,
the
issue
is
in
the
registries,
there's
a
message
queue
for
the
clients,
and
these
are
well
structured
messages,
and
the
fact
matter
is
that,
when
the
clients
connect,
they
specify
what
services
they
support.
There
may
be
an
instance
where
the
message
has
a
extension
that
the
client
does
not
support.
So
the
question
was:
what
should
the
server
do
and
then
there
was
a
question
around
what
is
the
intent
within
the
RFC's
themselves?
So
we
described
the
problem.
D
We
talked
about
three
different
options
to
address
it,
which
in
essence
is
we
do
nothing.
The
RFC
allows
for
the
server
to
return
things
that
the
client
does
not
support,
or
there
is
a
problem
and
it's
not
big
enough
to
do
anything
about,
or
it
is
a
problem
in
that
we
should
do
something
about
it
and
come
up
with
a
common
solution.
So
what
we
did
was
he
head
up?
We
had
a
lot
of
discussion
related
to
alternatives
to
actually
coming
up
with
a
solution.
D
There
was
a
example
of
returning
a
in
error
with
message
queue
information.
There
was
a
discussion
on
creating
a
filtered
queue,
which
it
only
has
messages
that
the
client
supports,
providing
a
priority
queue
which
will
in
essence,
only
return
the
message
that
they
support
first
and
then,
after
that,
it
will
turn
an
error
another
one
that
we
said
was
to
be
able
to
reformat
the
poem
message.
So
therefore
it
is
protocol
compliant,
but
will
still
provide
the
information
to
that
client
for
later
processing.
D
So
the
results
of
this
was
that
it
was
clear
that
there
is
a
problem
from
a
protocol
perspective.
Many
agreed
that
the
protocol
should
not
or
the
service
should
not
return
back
extensions
that
the
client
does
not
support.
The
question
was
coming
down
to
whether
or
not
this
is
a
policy
decision
or
a
technical
one,
and
with
that,
with
those
three
options
it
looked
like
there
was
more
support
for
this
being
a
problem,
but
there's
not
need
for
a
solution
for
it,
but
with
that
I
believe.
D
The
next
step
is
for
me
and
Martin
to
create
an
internet
draft
at
least
define
what
the
solution
that
we
proposed.
It
would
be
up
to
the
working
group
whether
or
not
to
take
this
on,
but
I
believe
it
is
a
problem.
I
believe
it
needs
to
be
fixed
and
we
will
go
ahead
and
create
an
inner
graph
to
define
that.
So
that's
it.
A
F
Roger
I
agree
with
Jim
I
think
that
there
is
the
identification
of
a
potential
problem
there
on
the
server
side,
I'm,
not
sure
how
big
of
a
problem
it
is
and
I
I
think
it's
a
good
idea
if,
if
Jim
wants
to
take
it
on
that,
he
documents
what
the
problem
is
and
what
possible
solutions.
There
are
again
I'm,
not
sure
I'm
sure
that
it's
a
priority
thing
definitely
wouldn't
bump
up
on
my
list
of
work
items
to
look
at
so
just
my
two.
A
It's
certainly
a
question
and
we
can
examine
whether
or
not
things
are
set
up
in
a
way
that
the
right
thing
is
happening
or
not,
but
that
was
my
pushback
at
the
time,
but
we'll
we'll
save
that
for
a
future
discussion
about
it
all
as
we
as
we
settle
on
until
okay
I'm,
not
seeing
anyone
else,
jumping
up
to
the
microphone,
so
I
guess
there's
no
other
questions
from
folks.
That's
fine,
so
Francisco
want
to
tell
us
he
talked
yesterday
a
bit
about
our
gap,
search
capabilities
and
authentication.
I
I
I
A
I
So
a
few
things
came
up
yesterday
on
this
session.
Well,
I
guess:
I
first
shall
explain
quickly
what
this
is
about
and
for
those
that
were
not
there
here
yesterday,
so
our
table
has
some
limited
search
capabilities
defined
in
RFC
77042,
one
of
the
quarters
of
the
RFC
yesterda
scared,
us
and
I
think
I'm
sure
of
a
real
specification.
That
was
fine,
a
last
minute
that
meets
in
serious
improvement
and
but
the
motivation
for
this
to
doing
this
now
is
because,
as
part
of
I
can
forth
on
GDP
our
compliance.
I
There
is
a
temporary
specification
of
was
fine
with
this
and
one
of
the
things
that
is
defining
the
term
spec,
although
some
people
contend,
that
is
that
they
are
coming
to
offer
our
dub
search
ability
and
there
are
specific
requirements
on
that
regard.
So
one
of
the
suggestions
from
yesterday
was
to
move
the
searches
to
use
regular
expressions,
as
has
been
proposed
by
Scott
and
others.
There
is
already
a
drop
on
on
this
regard.
I
The
result
there
was
also
the
point
raised
that
we
need
to
do
a
serious
review
for
internationalization
to
make
sure
that
searches
work
correctly.
Since
we
will
be
dealing
with
data,
that
is
not
just
a
ski,
since
we
will
be
talking
about
feels
like
a
contacts
name,
for
example,
and
what
else
there
were
some
concerns
about
the
resources
that
will
be
used
on
the
server
side
and
the
mechanics
to
deliver
potentially
large
result
sets
on
this
regard.
I
A
A
You
know
in
the
in
the
last
round
of
gTLDs
and
in
the
ICANN
world
there
was,
you
know
some
comments
about
how
to
support,
search
and
what
you
needed
and
how
it
applied.
Everything,
but
I
think
we
have
an
opportunity
here
to
really
step
back
and
look
at
this
from
a
technical
point
of
view
and
really
think
about
what
is
the
right
thing
to
do
and
and
the
right
way
to
to
provide
that,
so
that
the
policy
considerations
have
something
to
build
on
something
more
a
good
foundation
in
which
to
build.
A
Okay,
Oh,
wrong
set
of
slides
got
to
go
back
over
here.
Okay,
that
was
the
end
of
the
working
group
sent
my
assistant,
and
that
brings
us
down
to
any
other
business.
Yay
we've
actually
given
people
back
we're
just
about
at
20
after
the
hour.
So
you
know
that
gets
us
to
a
little
bit
of
an
early
place,
which
is
nice
few
minutes
early.
Anybody
have
any
comments
about
anything
at
all.
Anything
we've
talked
about
haven't
talked
about
something
you
want
to
talk
about
open
door
and,
if
not,
you
know,
I
I
think
again.
A
I
want
to
want
to
thank
people
for
keeping
up.
We've
had
quite
a
productive
year
this
year
in
and
finally
closing
loop
and
a
number
documents.
So
you
know
thanks
again
for
that
and
let's
see
if
we
can
keep
our
energy
going
as
we
move
into
to
to
new
work
items.
So
thanks
everyone
and
we'll
see
you
on
the
mailing
list.