►
From YouTube: IETF102-REGEXT-20180716-1550
Description
REGEXT meeting session at IETF102
2018/07/16 1550
https://datatracker.ietf.org/meeting/102/proceedings/
C
A
D
D
Short
I'll
only
observe
myself,
I'm
James
Galvin
I'm
co-chair
with
Antoine
Gursharan,
who
you
should
be
able
to
see
up
there
on
the
Medeco
he's
got
his
picture
up
there
at
the
top
and
I
see
that
we
have
a
number
of
remote
participants
and
and
I
think
that's
great
I'm
gonna
turn
this
meeting
over
right
away
to
Ryder
who's.
Gonna
kick
off.
The
first
topic
that
he's
gonna
go
through.
I
will
shortly
get
into
the
jabber
room.
D
Soon,
as
I
get
my
machine
rebooted,
it
has
decided
to
go
crazy
here,
so
I'll
simply
help
you
moderate.
The
discussion
keep
an
eye
on
the
meet
echo
and
the
jabber
room
for
people
who
want
to
make
comments
and
have
them
read
out
and
try
to
help
manage
the
queue
as
necessary,
but
otherwise
I'm
gonna,
let
Roger
and
then
James
you
know,
take
care
of
their
meeting
and
their
discussion
themselves
as
we've
done
with
interim
meetings
in
this
working
group.
Okay,
any
questions
or
comments
from
anyone,
the
blue
sheets
are
working
their
way
around.
D
D
Know
I
mean
just
to
be
clear
right,
as
with
all
ITF
work,
I'm
treating
this
kind
of
like
an
interim
meeting,
and
we
haven't
made
a
point
actually
in
our
interim
meetings
of
putting
the
note
well
up
there
on
the
sides.
I
mean
we'll
certainly
have
it
tomorrow.
When
we
have
our
more
formal
working
group
meeting
and
update
I,
don't
know
I,
don't
think
I'm
breaching
any
protocol
by
not
putting
it
up
on
the
screen,
but
I'll
at
least
point
out
the
folks.
D
Please
know
well
everything
you
say
and
do
here
you
know,
belongs
to
the
IETF,
and
you
know
we
do
have
some
rules
and
procedures
about
you
know
what
do
you
say
what
it
means,
what
can
be
done
with
it?
Appropriate
behavior
and
code
of
conduct
and
you've
seen
many
references
to
those
BCPs
and
other
working
groups.
You'll
see
it
here
tomorrow.
Please
do
make
sure
to
look
at
those
so
that
we
can
all
be
respectful
and
honorable
of
what
it
means
to
be
here.
The
idea.
So,
thanks
for
that
Roger
and
back
over
to
you.
F
Thanks
Jim,
all
right
so
I'm
here
to
run
through
registry
mapping
and
hopefully
get
some
conversation
going.
The
last
IETF
we
did
this
at
in
March
was
really
good.
We
had
a
lot
of
good
discussions
so
today
I'm
just
going
to
give
a
brief
overview
of
what
we're
talking
about
just
in
case
there's
some
new
people
or
some
people
that
fell
asleep
last
time.
F
Whatever
reason
I'll
give
a
brief
overview,
then
we'll
get
into
some
of
the
discussions
that
we
had
left
open
from
the
last
meeting
and
then
end
up
with
maybe
some
longer
discussions
on
some
of
the
items
they
hit
the
mailing
list
since
then
about
this.
So
alright
registry
mapping
is
a
dream
that
I
think
at
least
one
large
registrar
has
that
will
get
registries
to
promote
all
of
their
systems
in
a
consistent
way,
and
what
I
mean
by
this
is
is
GoDaddy?
Has
a
30,
40,
page
onboarding
questionnaire
for
every
registry?
F
So
if
you
have
a
new
TLD
starting
and
GoDaddy
is
looking
to
sell
that
we
actually
have
30
or
40
pages
of
300
plus
questions
to
ask
every
registry
and
I
mean
every
registry
operator.
Just
because
your
registry
doesn't
mean
you're
doing
the
same
thing
for
the
next
TLD
so,
and
one
of
the
big
reasons
we
do
it
is
is
to
try
to
get
the
same
questions
out
of
every
configurable
option
and
I'll
just
bring
up
the
one
big
one
that
I've
been
working
on.
F
It's
the
fee
document
of
okay,
the
fee
document
prescribes
how
to
run
the
fee
extension,
but
it
doesn't
make
explicit
statements
on
the
shoulds,
the
maze
and
all
of
that
those
are
options,
and
what
a
registrar
needs
to
know
is
how
you
have
configured
your
system.
Is
that
a
May?
If
it's
a
May,
you
actually
implemented
it?
Then
let's
know
that
some
of
the
other
big
items
that
we
were
looking
at
this
for
is
consistent
language.
F
F
So
it's
one
of
the
big
goals
for
us
as
a
registrar
is
to
get
that
naming
consistent
so
that
we're
all
communicating
about
the
same
things
as
well
as,
hopefully,
some
discussions
around
this
getting
maybe
80%
of
the
configuration
of
a
TLD
documented
in
a
consumable
fashion,
not
in
an
SDK.
Some
are
published
on
somebody's
website
that
now
that
we
have
200
registries
that
we
had
to
go
find.
So
those
are
the
big
goals
for
us
anyway.
F
F
As
far
as
the
registry
mapping,
how
I
have
we've
got
it
started?
Is
it's
broken
out
into
three
main
sections,
really
one
being
the
system,
the
generic
system,
level
kind
of
things
like
password
rules,
things
like
that
connections,
any
of
those
kind
I'm
that
are
pretty
generic
to
an
SRS,
and
then
that
also
includes
the
zones
and
the
zone
being
you
know,
obviously
the
the
TLD
that
we
are
going
to
try
to
sell.
So
how
has
that
zone
configure?
Are
there
any
special
issues
with
it
two
ways
about
zones?
F
You
can
get
a
list
of
zones
from
VPP
and
then
you
can
also
delve
deeper
into
a
byte,
specifically
identifying
its
own,
that
you're
interested
in
and
then
the
third
big
point
I
think
on
the
three
breakouts
is
the
extendable
mechanism
of
the
registry
systems
to
explain
all
those
extensions
that
everybody's
using
launch
phase
MacPhee.
All
those.
F
Rfc's
that
everybody
uses
but
has
documented
somewhere
how
they're
using
it-
and
this
extension
section
actually
shouldn't
do
that
automatically
saying.
Yes,
this
is
how
we're
using
it.
This
is
what
you
know.
This
term
means
for
us
and
it's
not
an
option
for
this
registry,
but
it
is
for
that
registry.
So
those
are
the
three
main
big
sections
of
the
registry
mapping
document
I,
don't
know
if
anybody
has
any
questions
or
comments.
F
G
F
Thanks
God
anyone
else
overview
Jim,
you
want
to
add
anything
to
the
overview,
yep
yep
again
quick.
If
anybody
has
any
questions,
feel
free
to
ask
me
a
gym
after,
if
you
don't
want
to
ask
now
so
Jim
cold,
not
Jim
Gilman.
Thank
you
all
right.
So,
let's
move
on
to
discussions
that
we
had
coming
out
of
ATF
101
last
the
spring.
F
F
F
Again,
it's
something
we
can
post
to
the
list
just
to
see
where
that
was
brought
up
from
otherwise
we'll
probably
continue
with
vas
jobs
for
it
so
yeah,
one
of
the
big
questions,
whether
the
policy
extensions
again,
the
policy
extensions
being
the
description
of
how
a
registry
implemented
in
RFC
so
for
the
fie
document
was
this
may
implemented
or
not.
So
that's
what
the
policy
extension
is.
F
A
question
came
up
last
time
was:
should
that
be
built
into
the
original
extension
RFC,
or
should
that
separate
right
now,
because
this
is
a
new
concept,
we
think
that
we're
gonna
keep
it
separate
and
let
this
thing
live
for
a
while
before
we
make
suggestions
to
say.
Okay
extensions
should
include
this
as
a
new
section
or
whatever
so
Jim.
E
Yes,
Jim:
go
from
Verisign
yeah
I
mirror
your
comment
as
well.
The
fact
that
including
the
login
security
extension
I
thought
about.
Well,
maybe
it
might
be
a
good
time
to
put
the
policy
for
the
log
and
security
extension
in
there
that
I
really
didn't
want
to
tie
that
extension
to
this
until
it
pretty
much
it's
matured.
In
essence,
at
this
point,
I
think
separation.
It
makes
sense
until
there's
implementations
of
the
registry
mapping
and
that
it's
moving
forward
then
reconsider
it.
F
F
One
of
the
questions
came
up
was
how
to
handle
future
policy
definitions
and
I.
Think
that
what
we
came
down
to
is,
let's,
let
the
future
be
the
future,
and
let's
get
this
implemented
before
we
start
making
those
big
decisions
or
those
open
box
decisions
that
we
don't
know
how
so
questions
around
bootstrapping.
This
was
actually
a
fairly
long
discussion.
F
We
had
at
the
last
meeting,
and
maybe
it's
because
Registrar
Stephen
may
had
a
good
side
of
this,
because
the
goal
being
we
want
to
automate
this
as
much
as
possible
and
it's
going
to
be
an
EPP.
So
how
do
we
actually
get
to
that
data
early
enough
that
it
makes
sense?
So
one
of
the
problems
that
our
registrar
has
is
before
we
bring
on
a
TLD
to
sell.
F
We
have
to
have
a
contractor
with
the
registries
and
to
get
access
to
the
system,
the
SRS
that
contract
has
to
be
in
place
so
chicken
egg
problem
here
is.
We
have
to
have
a
contract
to
get
access
to
the
definitions
of
what
they
have,
so
the
discussion
was
bootstrapping.
How
do
we
do
this
so
that
the
definitions
help
the
contracting
process
along?
Not
the
reverse
way
and
in
many
different
ideas
came
up
and
simple
ideas:
simplest
I'll
just
provide
the
response,
output
and
whatever
format
on
email.
E
The
Jim
ghoul
again
so
yeah
we
discussed
a
little
bit
related
to
different
models
of
onboarding,
one
was
kind
of
more
manual.
In
essence,
you
would
have
a
structured
document
in
a
document
somewhere
on
that
way.
You
might
be
able
to
get
that
ahead
of
time
ahead
of
the
contract.
Take
that
in
and
load
it
into
your
configuration
manually,
then
I
would
call
it
like
semi
automatic.
Now,
since
you
might
be
I
have
access
to
OTE,
you
can
dynamically
pull
it
use
that
and
then
have
what
we
call
90%
of
your
configuration.
F
Yeah
and
some
of
the
issues
on
the
the
different
topics
in
the
ot1.
Typically,
a
registrar
still
needs
to
have
a
sighing
before
they
get
access
to
OTE.
So
we
still
run
into
that
problem.
I
know
that
for
full
transparency,
I
don't
like
this
idea,
but
it
was
brought
up
last
time
and
it
was
maybe
a
rest
site
that
you
can
actually
just
hit
rest
and
it'll
produce.
This
back
I
mean
even
if
it's
calling
into
the
SRS
on
the
other
side,
maybe
just
you're
all
out
there.
F
That
actually
does
this-
that
you
get
access
to
again
I'm,
not
I,
don't
like
the
idea.
It's
just
another
point
to
maintain.
We
already
have
an
EPP
system
that
we
are
maintaining,
so
let's
not
worry
about
creating
another
endpoint
that
we
all
have
to
attach
to
maintain
passwords
for
make
sure
it's
alive.
So
the
dish
wanting
to
be
clear
that
that
was
brought
up
I,
just
I
personally
from
GoDaddy
standpoint,
know
like
that
idea.
So
yep.
D
So
Jim
Galvin,
can
you
say
a
little
more
about
why
you
don't
like
that
idea.
I
mean
we're
only
talking
about
the
bootstrapping
phase
right
so
having
a
place
to
go,
get
it
for
that
purpose
seems
reasonable.
I'll,
give
you
a
chance
to
respond.
First,
know
that
and
I
think
that's
fair
question
I
think
that's
kind
of
what
was.
F
Brought
up
again,
it's
that
would
be
just
a
bootstrap
mechanism,
but
that
is
a
maintenance
point
that
now
you
have
to
maintain.
You're
gonna
have
to
get
passwords
for
to
get
into
it.
You're
gonna
have
to
the
registries,
will
have
to
have
that
spot
up
and
running
all
the
time,
not
just
it's,
because
whenever
a
registrar's
bought
on
so
they're
gonna
have
to
maintain
a
system
as
forever
that
responds
to
that.
D
So
Jim
going
again,
I'm,
not
I,
want
to
be
careful
to
not
suggest
that
I'm
actually
thinking
about
doing
this,
but
in
thinking
about
this
bootstrapping
problem
a
little
bit
I
mean
a
couple
of
things
occur
to
me.
One
is
I
certainly
appreciate
the
idea
that
there,
if
you,
if
you
have
a
different
place,
that
you
have
to
go
to
get
this
initial
mapping,
then
yeah
I
mean
as
a
service
provider
you're
now
adding
yet
another
thing
that
you
have
to
maintain
and
manage,
and
all
of
that
so
that's
certainly
a
point
we're
thinking
about.
D
But
the
more
interesting
point
here
is
hearing
about
questions
from
other
people
coming
from
others.
Would
this
necessarily
have
to
be
password
protected?
Why
couldn't
it
be
freely
available?
I
mean
in
principle.
You
know
about
the
registries
right.
Is
there
a
reason
why
you
wouldn't
want
stuff
to
be
there
just
curious,
yeah.
E
Mr.
zoobel
go
again
yeah.
How
do
you
another
access
point?
Won't
change
the
security
around
it.
In
essence,
whether
or
not
you
allow
anybody
access
ot
any
or
you
provide
another
portal
that
has
the
same
information
just
to
know.
The
protocol
doesn't
really
add
all
that
much
to
the
problem
set
no
solution.
H
Rick
will
home
Barrow
sign
em
as
far
as
having
that
stuff,
just
open
and
out
and
available
with
no
password.
Typically
at
registries,
you've
got
a
signed
paperwork
about
software
licenses
and
things
like
that.
You
know
sort
of
it's
more
than
a
click
through
EULA,
but
but
something
that
says
that
the
information
provided
is
under
various
non
disclosures
and
all
that
other
sort
of
stuff.
So
it's
not
like
stuff
that
just
posted
out
on
a
website
publicly.
D
Yeah,
so
just
Jim
Gavin's,
two
quick,
closing
comment:
I
mean
I,
agree
with
you,
Rick
I,
don't
just
sort
of
trying
to
think
through.
You
know,
sort
of
the
maintenance
issues
or
were
non
issues
and
whether
they
really
were
there
and
I
was
questioning
whether
everything
in
the
mapping
really
is
private
or
needs
to
be
protected
or
not
and
I.
Guess
it's
hard
to
say,
but
you're
right
there
could
be
some
particular
circumstances
where
there's
something
in
there.
D
You
really
don't
want
to
be
public
unless
you're
part
of
it,
but
in
reality
it's
just
the
operation
of
the
registry.
It
should
be
something
which
you
want
people
to
know
about.
Maybe
that's
moving
in
a
different
direction.
We
are
today,
but
just
sort
of
raising
that
question
to
see
what
others
think
yeah.
H
Rick
Wilhelm
again
yeah
again
it's
it's
not
something
that
once
someone
is
part
of
that
relationship
as
a
registrar
with
the
registry
open
to
be
sharing
that
typically
registries
are.
But
it's
it's
not
the
sort
of
thing
you
like
when
you
post
content
out
on
your
website.
You
know
at
whatever
your
registry
website
is,
and
it's
just
open
for
anyone
in
gen-pop
to
go
see.
So
that's
the
only
difference.
It's
part
of
a
part.
F
F
E
Yeah,
one
of
the
specific
elements
did
not
have
was
not
defined
as
optional.
So
in
essence
that
the
registry
did
implement
the
host
adder
model
that
they
wouldn't
be
able
to
use
the
registry
mapping
based
on
it
not
being
optional,
so
I.
Think
fundamentally,
we
just
need
to
look
at
how
we
would
model
it
in
a
host
ad
or
registry
I'm,
not
sure
how
many
host
adder
registries
there
are
out
there.
F
E
Actually,
there
was
a
message
that
came
this
morning
that
described
just
a
little
bit
more
and
the
example
was
for
our
GP.
In
essence,
if
the
only
RFC
that
was
referenced
was
the
domain,
whether
or
not
it
would
include
the
reference
to
the
RTP
extension
which
pretty
much
our
sub
statuses
off
the
base
domain,
so
I
think
there's
something
that
we
could
take
a
look
at
to
see
whether
or
not
we're
covering
all
the
various
are
seeing
for
statuses.
But
I.
F
H
E
Have
to
admit
it
was
it
was
kind
of
thrown
in
late,
but
yeah.
There
were
two
other
options
put
on
the
list.
One
was
the
JAL
Machado
timer
and
there
was
another
one
from
Patrick,
so
I
think
we
fundamentally
just
need
to
look
at
how
to
best
define
a
batch
schedule,
and
so,
if
there's
any
suggestions
or
any
strong
feelings
anyway,
please
weigh
in
on
this
yeah.
F
I
think
we
don't
really
have
any
strong
suggestion
on
this,
and
it
was
you
right
Jim.
It
was
the
ISO
8601
that
Patrick
mentioned
and
again
I
I'm,
not
sure
that
as
authors,
we
have
any
specific
direction.
We
can,
you
know
we'll
pick
one
and
just
move
with
it.
Unless
someone
has
strong
objection
to
it
or
a
strong
need
for
one
of
the
other
ones.
So.
F
E
This
particular
item,
but
the
idea
as
I
understand
it
is
that
inside
the
registry
object
the
ability
to
define
all
of
the
elements
under
that
object.
So
the
only
question
there
is
that,
where
were
the
extensibility
plug-in
in
essence,
would
the
registry
object
need
to
define
a
new
extensibility
area
outside
of
what
I
defined
in
EPP
today?
So
my
position
was
just
use?
What
sensibility
is
already
defined,
with
an
EPP
and
in
the
case
of
my
experience
with
creating
the
policy
extension
for
the
launch
phase?
E
That's
one
example,
so
that
is
a
extension
of
a
zone
and
then
I
have
the
log
and
security
extension
which
into
creating
a
login
security
policy
extension
that
would
be
an
extension
of
the
system.
So,
if
you
think
about
the
object
model,
you
have
a
registry
which
has
a
system,
and
then
it
contains
many
zones,
and
so
when
you're
defining
extra
attributes,
you
can
define
where
the
extension
point
is
whether
it
be
system
or
zone
so
I'm,
not
really
exactly
sure.
It
might
be
good
if
Patrick
could
describe
how
you
would
add
extensibility
to
it.
F
F
D
Patrick
did
post
in
the
in
the
jabber
here
and
he
says
that
he
will
try
to
post
an
example
later
on
the
mailing
list,
but
basically
something
like
you
know:
registry
object,
type
equals
RFC,
57:31
is
the
the
leading
pipe
and
then
inside
you
would
have
the
opening
element
and
then
inside
you
have
all
domain
policy
items.
And
then
you
have
the
closing
slash
registry
object
and
he
just
puts
that
in
the
in
the
jabber
room
and
also
a
place
for
a
type
equals
quote.
D
F
No
problem
thanks,
Patrick
all
right.
The
next
item
that
was
brought
up
was
deletion
of
unused
objects,
hosting
contact.
It
was
something
that
wasn't
thought
about
being
in
there.
It
definitely
seems
like
a
good
idea
to
add
so
we'll
look
at
adding
that
I,
don't
know.
If
anybody
has
comments,
it's
definitely
something
that
we
continually
working
manually
to
do
things
like
that,
so
it'd
be
nice
to
get
defined.
F
E
Yeah
this
gym
again
so
when
I
was
reviewing
that
comm
I
was
thinking
well.
Okay,
so
are
their
registries
out
there
that
really
have
separate
policies
based
on
v6
versus
v4,
and
my
request
is
for
those
registries
that
do
have
separate
policies.
Please
help
in
trying
to
capture
that
in
this
because
for
us
we
don't
write
so
I.
Don't
want
to
speak
for
how
to
define
a
policy
where
I
don't
know
how
that
policy
would
is
defined.
So
I
believe
that
Patrick
is
aware
of
this
I
know
it's
not
Patrick
I.
E
F
Thanks
Jim
No
No,
maybe
I
skipped
this
one
I
didn't
want
to
think
about
it,
but
I
skipped
the
a
discussion
that
was
had
on
a
labels.
You
labels
LG
ours
and
if
we
should
be
actually
being
I,
don't
know
more
broad
and
using
more
specific
and
using
LG
ours
versus
just
saying
you
label
a
label,
support
it
or
not.
F
I
E
Yeah
this
is
Jim
Dugan,
so
I'm
thinking
about
it.
The
intent
was,
was
to
provide
a
high
level
description
to
the
client
of
what
the
main
names
are
allowed
right.
So
I'm
not
sure
whether
or
not
going
into
the
complexity
of
LG
ours
is
going
to
be
way
too.
Heavy
wait
for
this.
So
if
there
are
registries
out
there
where
the
attributes
don't
are
cannot
be
used
to
reflect
what
is
a
valid
domain
name
in
the
registry
that
I
suggest
speaking
up
and
providing
some
input.
F
Okay,
next
similar
I
guess
here
a
discussion
on
the
use
of
Lok
in
or,
as
in
some
registries,
allow
both
two
of
each
to
one
of
each
it
do
we
need
to
have
more
than
just
hey.
Lo
can't
does
it
need
to
specify
that
next
level
of
okay,
you
can
have
one
in
and
you
can
have
one
Lok
or
you
can
have
two
ents
or
to
Loucks
or
any
comments,
suggestions,
questions.
H
E
E
D
So
Jim
Calvin
I,
just
what
sort
of
channeling
Patrick
from
that
from
the
jabber
room,
I
missed
an
earlier
comment
from
his
but
focusing
on
this
particular
issue.
He
says
here:
no,
you
cannot
have
to
in
soar
to
Lopes
but
see
my
example
on
travel
in
the
mailing
list.
So
he
gave
example
about
that.
Go
ahead.
Jim.
E
D
E
I'm
just
saying
that
in
general,
when
we're
talking
about
registry
domain-name
rules
of
what's
valid
domain,
name
versus
what
code
points
can
be
used
in
a
with
a
specific
language
or
script,
is
something
entirely
different,
so
I'm
not
sure
for
onboarding
a
TLD,
whether
or
not
the
registrar's
need
that
level
of
detail
on
a
per
script
or
per
language
basis.
In
essence,
you
want
to
know
whether
or
not
ideas
can
be
supported
or
whether
that
you
can
provide
a
utf-8
domain
name
or
just
a
pure
ASCII.
F
D
And
I
guess
what
I'm?
What
I'm
wrestling
with
in
my
own
mind
is
you
know,
registries
I
feel
like
there's
a
distinction
to
be
made
here
between
DT,
LDS
and
cctlds.
You
know,
because
in
the
gTLD
world
we
do
all
tend
towards
wanting
to
do
things
in
a
similar
in
uniform
way
and
in
managing
all
of
that,
and
the
problem
is
see
CTL.
D
These
are
just
you
know,
they're
out
there
in
the
wild,
if
you
will
and
I'm
just
sort
of
thinking
through
in
my
mind,
gee
I
want
to
be
careful
here
that
we
don't
obligate
things
that
you
know
exclude
those
things
exclude
the
operation
of
cctlds
and
make
things
awkward,
probably
not
making
much
sense
here
on
my
point,
I
worry
as
a
service
provider
that
supports
both
that
I
can't
have
a
specification
here.
That's
gonna
make
it
hard
for
me
to
support
both
sets
of
customers.
That's
all
Rick.
H
D
Yeah
I
had
that
too
so
and
one
other
thing
just
going
back
a
bit.
Actually
a
patrick
made
a
high-level
comment
here
in
the
jabber
room
to
fall
out,
which
are
also
a
fair
comment.
He
says
here
you
cannot
expect
all
registries
to
be
there
or
hear
about
this
workgroup.
So
we
will
miss
cases
and
I
think
that's
kind
of
important.
D
H
D
F
F
F
D
F
No
problem
at
all,
and
then
there
was
a
few
just
a
few
quick
ones
here,
because
the
agreement
on
general
agreement
on
one
RFP,
which
one
is
it
domain
5050
371
domain,
one
states
that
domain
all,
as
is
valid
for
a
resetting
auth
info
code,
something
we
didn't
catch
in
the
registry
mapping.
Something
definitely
we're
going
to
add
into
there
how
to
handle
that.
So
moving
back
to.
F
E
Yeah,
this
is
a
slippery
slope.
I
just
want
to
tell
you
I
mean
you
have
registries
modifying
the
XML
schemas
doing
things
that
aren't
according
to
the
RFC
and
then
you
have
a
like
a
policy
extension
that
is
meant
to
define
how
it
works
and
then,
in
essence,
if
it's
not
RFC
compliant,
can
we
really
put
through
a
standards
track
extension
that
would
pretty
much
demonstrate
violation
of
the
RFC
s
right
to
me?
That's
just
not
a
good
thing
to
do.
F
Okay,
one
last
one
since
I
went
quick,
long
end
policies,
there's
been
a
draft
published,
you
did
publish
that
right,
Jim,
the
login
securities
yeah
draft
and
there's
a
discussion
of
what
what
pieces
of
that
actually
fit
in
maybe
more
of
the
system
level
of
the
registry,
mapping
and
I
think
we're
gonna
have
to
take
a
look
at
that
and
see
what
makes
sense
to
be
and
then
the
extension
verses
into
the
registry
mapping.
So
definitely
something
we're
gonna
look
at
and
see
how
that
fits.
So
that
was
less
comment.
Jim
cut
something.
E
F
D
A
couple
of
closing
comments
from
Patrick
just
to
read
out
here
so
about
contact,
IDs
I,
agree
in
the
technical
aspect,
meaning
not
grandfathering
variations,
but
then
the
other
side.
If
any
small
thing
it
is
not
possible
to
encode
in
this
new
extension
registries
will
not
use
it
and
you
are
back
to
the
40
pages
of
Excel
spreadsheet,
if
any
all
think
I'm
not
there's
more
missing
in
their
small
registries,
not
sure,
and
then
he
says,
the
question
is
really
which
registries
want
to
deploy
this
extension.
Any
small
thing
cannot
be
encoded.
D
Okay,
but
on
the
other
hand,
if
any
small
thing
cannot
be
encoded
in
this
new
extension
registries
will
not
use
it
and
you're
back
to
the
40
pages
of
Excel
spreadsheet.
So
the
really
important
question
is
which
registries
want
to
deploy
this
extension.
It
would
be
better
to
see
a
lot
or
many
of
them
do
it,
but
at
the
barriers
too
high,
no
one
will
so
I'm,
not
sure,
really
how
we
would
answer
that
question.
But
that's
an
interesting
question
to
ask.
Yes,.
E
Since
you
know,
there's
an
opportunity
for
these
registries
to
create
their
own
extensions
as
well.
So
if
there
is
someone
off
sort
of
thing
that
somebody
does,
you
can
create
an
extension
to
communicate
that
to
their
registers.
The
point
is:
is
that
by
pulling
in
something
that
is
a
went
off
into
the
base
in
essence
that
the
base
will
get
very
complex,
very
quickly
right.
D
So
maybe
maybe
the
thing
to
do
is
to
take
onboard
a
comment.
We
add
some
some
clarity
on
this
point
in
the
document
where
we
tell
people
you
know
this
is
explicitly
call
out.
This
is
the
base
line.
This
is
the
standard
if
you
need
a
deviation
for
whatever
reason
you
know,
go
off
and
add
your
own
and
maybe
that's
a
better
way
to
deal
with
it.
H
Yeah
Rick
will
embarrass
on
another
thing:
that's
interesting
is
that
adds
registries
start
and
evolve
and
grow.
Sometimes
there
are
people
at
them
that
do
things
that
they
don't
really
realize
the
side
effects
or
the
impacts
of
that
which
they
are
doing,
and
so,
therefore,
if
there
is
a
mechanism
by
which
those
sorts
of
things
can
get
called
out
of,
saying,
look
those
don't
fit
into
these
buckets.
That
is
the
general
consensus
and
therefore
you
have
to
go
in
to
an
extension
mechanism.
D
I
agree
with
you
Rick
I'm
laughing
up
here,
where
you're
talking
more
because
there
are
people
who
do
it
because
they
don't
really
care
but
facilitating
something
better
and
just
for
the
record,
you
know
Patrick
says
in
the
Tavor
room
to
that.
He
agrees
with
the
suggestion
that
I
was
making
about
as
long
as
it's
possible
to
easily
extend.
You
know
then,
and
we
should
just
clarify
that
that's
all
okay.
F
J
E
Yeah,
so
actually,
we've
had
a
lot
of
discussion
on
this
today
and
what
this
is
talking
about
is
the
unhandled
namespaces
scroll
down
yeah
so
where
this
originated
from,
as
we
were
going
through.
The
working
group
last
call
on
the
change
poll
extension
and
Martin
Casanova
brought
up
a
really
good
point,
where
I
really
didn't
have
a
good
answer
to
just
be
honest
with
you,
I
didn't
think
about
it.
E
E
In
essence,
since
it's
a
poll
Q
and
it's
a
top
message
on
the
Q,
do
you
not
allow
them
to
consume
that
message,
because
they're
not
going
to
support
it
or
in
essence,
would
you
return
it
independent
of
their
login
services?
That's
where
it
comes
down
to
right,
so
the
discussion
went
towards
really.
What
is
the
purpose
of
the
greeting
and
login
services
in
the
base,
EPP
RFC
and
the
end
result
for
the
change
poll
extension
is
that
this
is
not
unique
to
change.
E
Pool
extension,
this
exists
in
other
extensions
as
well,
and
so
we
wanted
to
have
a
broader
discussion
around
this
problem
and
not
hold
up
to
change,
pool
extension
because
of
this.
So
as
a
working
group,
you
really
have
three
options.
One
is
we
agree
that
there
is
no
problem
with
the
server
returning
back
services
that
are
not
included
in
the
login
services
of
the
client.
In
essence,
you
don't
have
to
do
anything.
E
The
second
is,
we
agree,
there's
a
problem,
but
it's
not
a
big
enough
problem
for
us
to
come
up
with
a
common
solution
and
then
the
third
is,
you
know,
there's
a
problem
and
we
should
fix
it.
So
let's
come
up
with
some
common
approach
to
address
it.
You
just
okay,
so
let
me
do
is
they're
going
to
jump
into
the
language
in
the
RFC's,
because
this
is
what
we're
kind
of
living
by
here.
E
So
if
you
look
at
the
definition
of
the
epp,
greeting
pretty
much,
it
says
identifies
the
services
supported
by
the
server.
That's
pretty
basic.
If
you
look
at
the
login
services
for
the
client,
it
identifies
the
object.
You
are
eyes
being
managed
during
the
session
and
it
may
contain
the
extension
of
your
eyes
that
may
that
would
be
used
during
the
session
right
now.
It
doesn't
say
that
you
can't
include
other
things,
but
I
think
that's
kind
of
implied,
so
in
essence
it
the
server
saying
this
is
what
I
support
and
the
client
says.
E
This
is
what
I
support.
How
strongly
do
we
enforce
that?
So
really
what
it
comes
down
to
is
that
should
the
server
accept
objects
or
extensions
provided
by
a
client
that
is
not
included
in
the
serve
and
the
greeting
services,
an
example
of
this
would
be
what
if
the
client
sends
an
extension
to
a
domain
command,
that's
not
included
in
the
green
services.
I
can
tell
you
from
our
perspective.
We
would
fail
it
right
and
there's
an
error
code
to
represent
that
today,
but
there
may
be
registries
out
there.
That
would
ignore
it.
E
So
what
to
do
is
I'm
going
to
jump
down
here
and
I
had
said
that
there
are
other
extensions
that
that
have
this
same
issue.
We
cover
the
change
poll.
There's
a
poll
message
in
the
launch
page.
There's
a
poll
message
in
the
key
relay
right:
there's
been
discussion
around
the
DNS
SEC
extension
as
well.
There's
language
in
that
RFC
associated
with
transitioning
from
Venus
equiano
to
1.1.
E
There's
language
in
the
registry
fee
extension
related
to
whether
what
to
do
if
the
client
does
not
support
the
registry
fee
extension
and
there's
also
language
within
the
bundling
extension.
So
the
point
is
is
that
this
is
not
unique
to
the
change
poll.
It's
not
unique
to
poll
messaging
and
there's
been
discussion
even
today,
related
to
the
desire
for
clients
potentially
to
get
information
to
know
that
before
they
mean
they
may
not
even
support
it.
E
So
we're
going
to
do
here
is
going
to
pop
down
to
revisiting
these
options,
and
I
really
want
to
hear
from
you
on
this.
So
the
first
option
is
that
there's
no
problem
in
essence,
the
RFC
supports
servers
returning
back
services
that
are
not
included
in
the
login
services
of
the
client.
The
other
is
there
is
a
problem,
but
it's
just
not
important
enough.
Nobody
has
really
gotten
hurt
from
this
and
then
the
third
is
it's
a
problem.
We
should
come
up
with
a
solution
for
it.
So
are
there
any
opinions
on
this.
G
Scot
Hollenbeck
here
so
Jimmer
when
you
first
started,
you
asked
about
intent
at
least
I
heard
that
word
mentioned,
and
as
the
guy
that
wrote
that
text
I
can
tell
you
what
the
intent
was.
This
is
intended
to
be
handshake
right
where
the
server
says
I
do
these
things.
The
expectation
would
be
that
the
client
would
then
come
back
and
say
that's
great.
You
do
those
things.
G
I
wish
to
take
advantage
of
either
this
subset
of
those
things
or
the
entire
set
all
right,
and
so
it's
kind
of
similar
to
the
server
saying:
hey,
I,
speak
English
in
French
the
clients
saying
I,
speak
English
and
German.
Well.
If
the
client
then
tries
to
talk
to
the
server
in
German,
the
server
doesn't
understand
that
right
and
generally
you're
not
going
to
get
a
response.
G
So
in
the
case
here,
I
think
well,
III
think
there
would
be
a
problem
if
the
server
says
I
do
XY
and
Z
or
Zed
I'm.
Sorry
we're
in
Canada
and
if
the
client
says
I
do
you
know
X,
Y,
Z
and
a
well
at
that
point
the
server
should
say:
well,
that's
great
I!
Don't
do
a
so
we
aren't
going
to
have
a
session.
E
G
G
My
thought
there
was
that
the
server
would
then
not
attempt
to
push
contacts
on
to
the
client
right,
because
the
client
has
already
told
you
hey
I,
don't
speak
that
language
I,
don't
understand
it,
so
don't
give
me
something:
I
can't
consume
now.
This
gets
a
little
bit
more
interesting
when
you're
talking
about
extensions,
but
but
having
said
that,
I
think
in
that
that
was
the
spirit.
K
E
K
K
I
K
E
F
This
writer
and
I
guess
I'll
have
to
kind
of
agree
with
that.
I
mean
I,
think
that
there's
probably
technically
our
problem
or
could
be
a
problem,
but
as
a
registrar
that
does
process
these,
we
don't
have
a
problem
if
things
got
on
there
that
weren't
supposed
to
be
there,
because
we
have
code
that
handles
that.
So
I
think
I
had
another
point
and
I'm
trying
to
remember
what
it
was
now.
E
On
the
list
it
was
communicated
such
like,
for
example,
I
think
it
was
Patrick
that
was
saying
well
if
the
DNS
extension
was
not
including
the
login
services
and
the
domain
was
Dean
ASEC
enabled.
Should
the
registry
returned
back,
the
extension
and
I
would
say
no
that's
based
on
the
protocol?
No,
but
they
may
did
there's
language
in
there
related
to
transition
between
the
earlier
version
of
the
Deena
sec
extension
and
the
newer
one.
G
Scot
Hollenbeck
no
I,
wouldn't
say
that
I
I
tend
to
fall
into
the
camp
of
you
know.
If
you
get
something
that
you
don't
understand,
that's
not
a
reason
to
go.
Kaboom
right
and
I,
see,
I,
see,
I,
see
one
place
where
implementations
might
not
agree
with
that
I
mean
if
you're
doing
a
you
know,
schema
validation,
for
example,
and
if
your
code
is
implemented
in
such
a
way
that
you
get
something
that
you
don't
account
for
and
your
schema
validator
goes
kaboom.
You
know
that
might
be
enough
to
bring
you
down.
I
think.
G
If
that,
if
it
happens,
that's
a
bad
implementation.
You
know
you
should
write
your
code
in
such
a
way
that
you
know
that
type
of
a
data
formatting
or
data
consistency,
error,
gets
caught
and
is
addressed
appropriately,
so
I
think
I
tend
to
fall
more
into
the
the
camp
to
arbitrate
camp
number
two
here
and
that
what
we
might
want
to
consider
doing
is
simply
writing
some
text
some
place.
That
gives
guidance
to
implementers
that
you
know.
If
this
is
the
situation
in
which
you
find
yourself
right,
don't
don't
go
kaboom.
G
E
That's
interesting
I
come
from
a
different
perspective
and
it
might
be
because
I'm
one
of
the
primary
authors
of
a
client-side
SDK
that
does
happen
to
validate
so
in
thinking
through
the
basic
assumption.
I
know
the
assumptions
a
bad
word,
but
in
essence
was
that
the
server's
would
honor
the
login
services.
E
So
therefore,
for
example,
in
the
client,
it
will
merge
all
of
the
supported
services
with
what
its
returning
the
green
to
ensure
that
not
more
services
are
returned
back
in
the
login
services
and
in
fact
it
if
all
sudden
the
server
starts
returning
things
that
that
that's
not
supported,
then
it
will
go.
Kaboom,
mm-hm
I
know
for
a
fact
that
a
little
bit
kaboom
and
there
might
be
other
clients
I
may
go
kaboom.
G
D
E
D
D
D
E
Not
me
all
right,
so
anyways
the
if
we
went
with
option
one
or
two:
these
are
the
side
effects
for
potential
or
potential
client
issues.
The
first
is
and
Scott
pointed
out.
If
you
have
a
validating
XML
parser,
it
will
go
kaboom.
It
will
not
find
the
schema
based
on
a
URI
and
it
will
fail.
Then
you
have
a
Poisson
pull
message
right
now.
The
client
could
disable
the
XML
schema,
validation
and
our
client-side
SDK
allows
for
that.
Then
it'll
get
to
the
next
one.
E
So
next
one
is
that
typically
clients
aren't
using
Dom
directly
right.
They
are
going
to
marshal
it
to
domain
specific
objects
and
then
that's
where
I'll
go
kaboom
at
that
point.
So
generally
will
one
of
happens.
That
will
be
a
factory
per
namespace
it
won't.
It
will
look
for
the
factory
won't
find
it
in
a
local
boom.
E
E
My
main
concern
is
that
the
foundation
itself
is
not
solid
and,
if
all
of
a
sudden
were
accepting
the
fact
that
the
service
can
return,
this
information
that
the
clients
need
to
do
defensive
programming,
you
can't
prot,
you
have
to
account
for
this
right,
so
all
right,
so
what
I'm
gonna
do
is
I'm.
Gonna
jump
no
go
ahead.
E
D
Jeff
Gallen
I
mean
I,
guess,
building
on
that
and
kind
of
agreeing
with
you,
I
actually
don't
know
for
sure
what
we
do
in
our
ot
any
environment.
One
of
the
things
that
occurred
to
me
as
well-
well,
gee,
you
know
I
mean
we
would
put
an
example
of
all
the
poll
messages
out
there
and
they
should
be
doing
that
and
in
OTE
right
shouldn't,
they
I
mean
I,
actually,
don't
know
for
certain
we
do.
I
would
presume
that
we
do
so
I
agree
with
you.
In
that
sense,
this
should
never
happen.
E
D
I
will
channel
Martin
cousin
over
here
in
the
in
the
chat
room.
He
says
that
I,
don't
think
creating
a
poisons
message
is
a
good
option.
Only
alternative
I
see
is
to
not
send
any
extension,
an
old
message
that
was
not
specified
at
all.
You
know.
Both
message
of
both
cases
are
heed
for
registrar's,
but
yeah
anyway.
E
Well
well,
this
is
what
if
there
was
interest
in
option
three
and
to
come
up
with
a
common
solution,
these
were
the
four
items
discussed
on
the
list.
The
first
one
is
really
not
an
option
just
want
to
point
out,
but
just
to
complete
it
serve
returns,
an
error
that
will
create
a
poison
message.
The
second
one
is
that
you
would
create
a
specific
extension
of
an
unsupported
extension
which
is
kind
of
a
chicken
in
the
egg,
so
create
an
extension
to
say
that
you
don't
support
an
extension
yeah.
E
Okay,
number
three
was
the
first
I
would
say
real
option
presented,
which
was
to
leverage
the
message.
Queue
message
element
to
include
the
namespaces
that
are
not
supported.
We've
been
asked,
since
you
would
filter
them.
You
would
put
the
namespace
in
the
message,
queue
message
element
and
then
that
way,
it's
protocol
compliant
and
the
clients
received
the
information.
That's
what
what's
not
supported
the
issue
with
this
one
is
the
fact
that
that
element
is
meant
for
human,
readable
messages
and
not
machine
personal,
and
then
Martin
came
up
with
a
great
eye.
E
I
really
like
this
idea
was
use
the
existing
EXT
value,
an
element
which
has
two
out
the
two
sub
elements
to
it.
One
is
a
value
and
the
other
is
a
reason
they
eat.
The
value
is
contains
XML
and
the
fact
that
matters
that
there
can
be
many
of
these.
So
there
could
be
one
purl,
unsupported
namespace,
so
I'm
going
to
cover
these
real,
quick,
we'll
go
through
these.
The
first
one
was
example
of
okay,
good.
M
E
M
E
M
E
E
M
E
M
We
have
a
realistic
case,
that
is,
that
the
NSA
implementation,
because
we
are
starting
known
and
we
have
the
nsx
neighbor
registrar
and
not
dns,
actionable
registers,
and
we
we
are
choosing
to
to
remove
the
dns,
a
crustacean
element
from
the
domain
name
for
response
for
it,
for
example,
the
real
problem
in
the
whole
message,
I
think,
is
that
the
response
can
contain
only
extension
element.
Only
this
tension
element.
E
M
E
G
Let's
cut
Hollande
back
again,
so
I
need
to
go
back
as
something
Jim
said
a
little
while
ago,
generally
implementations
that
follow
the
protocol
are
not
going
to
have
this
problem
right.
So
we
have
implementations
to
follow
the
protocol,
implementations
that
don't.
Why
do
we
think
that
adding
elements
to
the
protocol
are
going
to
address
issues
with
implementations
that
aren't
implementing
the
protocol
correctly?
G
E
I
think
they,
the
client,
is
implementing
the
protocol
correctly
right
and
if
the
server
returns
back
information
to
pull
queue,
that's
generated
by
the
server
in
this
instance
right
that
it
does
not
know
the
services
that
the
client
supports
when
they
eventually
log
in
correct.
So
if
you
have
a
change
pol
based
on
change
to
a
domain,
let's
say,
and
then
the
client
logs
in
and
does
not
support
the
change
pol
extension
so
their
work.
The
question
is:
is
that
what
should
the
server
do
with
that
poll
message?
E
E
E
G
G
G
D
In
from
my
mind,
let's
do
Patrick
first,
he
says
not
agree
completely.
If,
on
day,
X
a
registry
starts
to
add
a
new
URI
to
the
greeting
and
the
client
does
not
use
it
and
the
login
is
authorized.
Hence
this
extension
is
not
mandatory.
Then
the
client
is
conforming,
but
there
could
still
be
the
problem
of
the
server
having
a
message
with
a
namespace,
not
understood
by
the
client,
which
is
it,
which
is
good.
I
mean
that
what
I'm
struggling
with
here
when
I
think
about
this
is
maybe
to
refrain
I.
D
D
G
Now,
indeed,
as
you
said,
what
that
means,
that
is,
that
the
server
may
be
holding
back
messages
that
never
get
polled,
because
the
client
never
says
I'm
willing
to
accept
them,
and
the
logical
conclusion
of
that
is
that
at
some
point
well,
there
may
be
valuable
information.
They're
not
getting
okay,
but
they've
said
they
don't
want
it.
The
expectation
should
be
that
the
server
has
every
right
to
purge
those
messages
from
the
queue
at
whatever
point
they
feel
is
appropriate,
but.
E
E
G
E
G
That
they
can't
consume
because
they
were
given
that
information
when
they
received
the
greeting
from
the
server
the
service
that
look
I
can
process
these
Qi.
This
other
type
of
messages
now
they're
not
getting
an
indication
that
they're
actually
are
in
queued
messages
there,
but
the
assumption
is
if
that
extension
is
supported
by
the
server.
The
client
should
expect
that
they
may
have
messages
queued
that
I'm
sorry
extension
messages
queued
for
that
particular
extension.
Does
that.
E
Make
sense,
yeah
I'm
just
trying
to
think
that
it
would
be
some
not
very
transparent,
right,
there's
nothing
in
the
protocol.
That
would
define
that
you'd,
probably
be
better
to
say
there
are
actually
messages
in
the
queue
and
return
back,
an
error
that
you
can't
get
it
because
you
don't
support
it
right.
G
That's
also
a
possibility
right.
Yes,
if
they
say
hey
give
me
what's
in
the
queue
instead
of
saying
nothing,
it
could
be
like
something,
but
you
didn't
accept
them
right.
That
may
actually
be
more
effective
and
that's
a
clue.
Then
maybe
I
should
go
back
and
rethink
what
I
did
on
the
login
right.
So.
E
D
Well,
just
to
read
out
while
you're
scrolling
there,
what
patrick
says
in
the
room
here
agree
with
James
I
assume
he
means
you
you've
been
doing
most
of
the
talking
recently.
This
is
not
transparent.
The
registry
can
start
in
queueing
new
messages
with
new
URI
and
the
Registrar
is
already
in
an
EPP
session.
D
Now
you
wouldn't
know
yeah
I,
I,
guess
I,
don't
know
what
the
right
answer
is
here.
I
mean
I,
agree,
there's
a
problem
and
I'm
sort
of
thinking
through
is.
This
is
a
problem
that
we
need
to
solve
or
not
I,
don't
know.
It
depends
to
some
extent
what
you're
actually
putting
in
the
queue,
and
the
significance
of
that
is
poll
messages
I
think
to
some
extent
are
I'm.
D
Gonna
use
a
particular
term
to
put
a
particular
spin
on
it
or
just
informational,
so
they're
not
transactional,
like
PPP
is
so
where
you
actually
have
to
deal
with
everything,
and
in
that
respect
it
should
be
okay
to
just
delete
them.
But
that
also
means
that,
as
you
create
extensions
for
poll
messages,
you
have
to
be
careful
that
you
don't
overstate
the
value
of
that
message,
because
if
you
do,
then
we
need
a
mechanism
for
dealing
with
the
fact
that.
E
Is
are
in
queues
not
only
that
you
need
to
deal
with
what
should
the
server
return
that
we
talked
about?
Yeah,
they'll,
filtering
it
and
return
an
error,
and
you
know
there's
a
there's
different
things
that
you
could
choose
from
I'm,
just
going
to
point
out,
one
of
them
and
I
think
this
will
work.
This
is
from
Martin
and
in
this
particular
age
that
doesn't
show
up
there.
E
Other
is
we
got
it?
Okay
just
went
to
sleep
all
right,
so
in
this
example,
one
of
the
ideas
is
the
fact
that
the
server
can't
filter
right.
In
essence,
if
based
on
the
login
services,
let's
say
the
change
poll,
the
change
poll
is
not
supported.
So,
instead
of
returning
an
error,
if
it
turns
back
to
the
message
with
the
message
ID,
so
they
can
add
it
and
there's
one
modification
on
this-
is
that
the
fact
that
the
x
value
element
that
value
M
is
actually
XML.
E
You
can
include
the
full
block
of
XML
of
the
unsupported
extension
in
there
and
the
beauty
of
what's
got
defined
in
the
XML
schema
the
base
RFC's
the
fact
that
the
parser
will
not
parse
that
validated.
So
the
idea
is
the
fact
that
the
client
truly
does
not
support
the
change
pull
message.
They
can
still
get
the
message:
it's
not
going
to
be
in
the
the
appropriate
place
that
would
make
it
go
kaboom
by
the
XML,
parser
it'll
be
there.
E
They
could
process
it
later
and
if
they
get
this
message,
that
can
it's
an
indication
then
that
they
need
to
fix
something
on
their
end
right.
The
idea
here
is
that,
and
the
beauty
of
this
as
well
is
that
there
is
one
ext
value.
That's
a
list.
So
therefore,
if
you
had
multiple
extensions,
you
could
have
one
per
extension,
so
this
is
not
hard
to
do.
I've
actually
implemented
it
in
a
stub
server.
D
Okay,
so
Jim
Galvin
and
I
guess
I'll
just
speak
in
comment.
I
mean
I,
won't
object
to
this
kind
of
thing,
but
I
think
I'm,
just
gonna
go
back
to
the
question
that
great
before
I
mean
what
problem
are
we
solving
and
and
I?
Just
you
know,
I
just
don't
see
the
value
in
this
I.
Don't
see
myself
wanting
to
do
this.
You
know
if
the
poll
messages
really
are
informational.
In
that
sense,
the
Registrar
is:
are
they
going
to
keep
up
or
they're?
D
Not
it's
it's
on
them
to
do
the
comparison
of
the
login
greeting
and
and
see
if
there's
something
there
that
they
are
not
supporting
and
take
note
of
that
and
it's
just
my
responsibility
as
a
as
a
server
to
you
know
not
put
anything
in
the
poll
queue
that
I
think
is
important.
I
guess
I'm
not
even
sure,
quite
sure
how
to
say
that
that
is
non
informational,
but
I
think
we
do
that
anyway
in
the
standards
process,
as
we
create
the
poll
messages
right,
so
we,
but
then
what
you're
doing
in
the
process.
D
Yeah
I
mean
I'm,
just
gonna
delete
them
if
they
don't
consume
them.
I'm,
eventually
just
gonna
delete
them,
but
you're
not
gonna
return
back
an
error.
That's
right
right,
so
you
are
going
to
return
back,
but
that's
right,
I'm
trying
to
figure
out
if
there's
a
problem
that
I'm
solving
that
benefits
me
right,
I
mean
that's
a
bet.
D
E
You
right
so
in
essence,
you
were
not
following
the
RFC,
if
you're
returning
back
there,
services
that
are
not,
who
is
they
you,
the
client
to
the
server
the
server
the
server?
If
the
server's
returning
back
a
change,
pull
on
the
clients
that
they
don't
support
in
the
login
services,
they
are
doing
everything
according
to
the
RFC.
You
are
not
so.
The
question
is:
is
that
part
of
this.
D
Embrace
it
relieves
me:
do
it
yeah
differently,
I
think
the
question
there
is
yes,
the
client
is
not
implementing
something
that
the
server
is
expecting
them
to
write,
and
so
the
question
now
is
you
know
how
much
do
I
care
about
that
as
a
server
okay,
I
mean
if
I
care
enough
about
it,
then
presumably
I'm
gonna
do
something
to
make
sure
that
all
of
my
registrar's
support
all
of
the
things
that
I
want
them
to
have,
and
you
know
that's
that's
an
external
right
meta
issue.
That's
going
on!
D
That's
a
whole
oat,
Eenie
kind
of
thing:
I'm,
gonna,
roll
out
a
new
feature,
I'm
gonna
find
a
way
to
make
sure
our
all
the
registrar's
know
about
it
as
clients
know
about
it
as
a
server
but
other
than
that,
if
you're
a
client
that
didn't
implement
it
and
I'm
giving
it
to
you
if
you're
not
interested
in
consuming
it.
The
question
is
to
me
as
to
how
important
it
is
that
you
consume
it.
D
G
It
it's
got
home,
but
yeah
and
Jim
into
your
point.
If
you
are
publishing
the
fact
that
you
support
a
B
and
C
and
as
part
of
the
log
game,
the
client
says
I'm
only
going
to
do
a
and
B
us
server
can
say.
Well,
that's
great
get
out
of
here:
I'm,
not
gonna.
Let
you
log
in
yes,
I'm!
Sorry!
If
those
of
you
couldn't
see
the
raspberry
I
just
demonstrated
okay
and
and
that's
the
end
of
it
right,
I.
D
Think
so
you
know
I
so
I
mean
I
I.
Don't
think
that
this
is
necessary
because
I
think
going
back
to
the
thing,
maybe
there's
a
problem
here
but
I,
don't
think
the
problem
needs
to
be
solved
in
the
standard
I.
Think
it's
a
it's
a
higher-level
problem
and
and
I
you
know
I
just
think
it's
not
something
to
do
least
I
haven't
been
convinced
yet
I'm
open,
but
he's
got
some
thoughts.
Scott.
D
Which
is
why
I
said
I
mean
just
speaking
as
a
registry.
I
wouldn't
object
to
this.
If
it
existed,
but
I'll
say
the
other
side
of
which
is
I,
can't
imagine
that
I
would
implement
it
because
yeah,
you
know.
If
I
want
you
to
implement
it,
then
I
will
make
sure
that
you
do
and
otherwise
I'll
just
delete
the
old
messages
you
know,
according
to
whatever
my
policy
is
gonna,
be
you
know
I,
because
just
going
back
to
the
whole
thing,
what
problem
my
solving
here?
What
would
what
benefit
am
I
getting
from
this
anyway?.
F
F
F
D
This
could
spec
to
the
other.
The
earlier
comment
way
back
in
the
beginning,
about
it's
not
possible
for
a
registrar
to
consume
things
that
they
didn't
expect.
If
the
registry
is,
if
the
server
is
doing
its
job,
the
Registrar
would
not
be
able
to
consume
something
it
didn't
expect,
and
so
you
wouldn't
have
a
poison
poison
bill.
I
E
I
The
fact
back
to
understanding
is,
if
we
will,
you
want
to
have
the
Registrar
implement
something
to
opt
ot,
any
and
stuff.
So
in
this
situation,
I
know
this
is
a
problem,
because
we'll
do
as
much
as
possible
our
communication
to
make
sure
that
registra
implemented
that
and
then,
if
they
log
in
the
saying
that
we
haven't
done
what
you
told
us,
and
that
is
not
a
problem,
because
we
will
not
create
any
message
that
anyone
will
not
consume
before
we
actually
communicate
that
ever.
I
That
we
will
not
return
anything
that
we
have
not
communicate
to
the
register
before,
and
that
is
not
a
problem
for
us
myself.
It
did
not
know
knowing
the
problem
they
have,
so
you
don't
see
that
technically
you
need
to
do
anything
since
you
communicated
it
in
a
notice,
because
the
technical
solution
proposing
is
to
to
accommodate
people,
don't
listen
to
you,
okay
and
and
that.
E
D
D
D
C
You
Jim
so
hello,
roan.
This
francisco
is
from
icon,
so
I
was
asked
to
talk
about
and
potential
new
stream
of
work
regarding
our
top
search
capabilities,
and
so
let
me
see
how
this
oh,
okay,
I
see.
So
the
current
our
dub
search
capabilities
as
specified
in
RFC
74
82
I,
took
the
liberty
to
highlight
Oh
today.
The
the
items
there
that
I
think
are
of
interest
for
this
discussion
is
one
is
you
can
do
partial
string
searching
using
the
asterisk
as
the
sort
of
the
Walker
I?
C
Guess
too
much
C
or
more
trail
a
meet
or
trailing
characters
and
the
another
important
thing
discussion
is
that
he,
the
way
you
understand-
FCM,
maybe
I'm
wrong
here
and
maybe
I
would
be
happy
to
be
corrected.
But
it
seems
like
if
you
have
multiple
query
matching
parameters.
A
there
is
an
implicit
or
to
join
the
the
sets.
C
Now
on
the
gTLD
side
of
things.
As
some
of
you
may
know,
there
is
recent
developments
made
using
may
a
pass.
May
there
was
a
new
specification
pass
for
detailed
erases
and
registers
regarding
the
GDP,
our
compliance
and
one
of
the
things
that
that
specific
specification
included
was
that
searchability,
which
was
previously
something
specified
only
for
web,
who
is.
It
is
now
also
required
to
be
over
in
our
the
for
those
that
committed
to
offer
that
service.
C
There
is
some
work
that
is
happening
right
now
to
finalize
what
we
call
the
the
profile,
which
is
a
specific
set
of
requirements
regarding
an
are
definitely
spec
and
a
space,
and
after
that,
a
I
can
book
acquired
implementation
of
our
dub
for
both
Italy
racism
registrar's.
So
once
that
happens
and
other
piece
of
equipment
to
be
implemented,
those
races
and
racers
that
are
offering
such
ability
will
have
to
offer
it
over.
Our
dub
to
a
couple
other
things
that
come
from
from
the
spec
regarding
sociability.
You
will
find
this.
C
This
is
an
aspect
of
was
not
including
the
time
spec
is
referenced
by
the
times
back
in
a
sense.
Respect
for
the
rest
of
the
the
elements
that
are
not
highlighted
here
are
in
the
register
remain
the
2017
based
ready,
remain.
Second
bullet
I
thing
is
simple,
and
it's
already
called
by
the
core
inspectors.
C
C
Sorry,
the
register,
women
by
reference
from
ten
spec
I,
guess
defines
a
set
of
fields
that
need
to
be
supported,
which
is
basically
everything
and,
and
we
I
believe
we're
currently
missing
the
capability,
for
example,
to
do
searches
on
the
my
names
based
on
an
entity
that
has
a
role
in
my
name.
So,
for
example,
looking
the
domain
names
are
linked
to
a
domain
name
by
the,
because
the
contact
with
a
specific
name
has
the
role
of
say
admin
contact.
C
So
with
that
in
mind,
potential
search
improvements
that
may
be
of
interest
for
italy's
and
maybe
some
disabilities,
even
if
they
are
not,
of
course,
bound
by
the
contract
with
ICANN.
There
may
still
be
interested
in
offering
these
capabilities,
and
so
maybe
we
need
to
add
some
capabilities
for
supporting
a
leading,
welker
I'm,
not
sure
if
that's
the
correct
reading
of.
If
my
reading
of
the
the
spec
is
correct,
but
then
the
register
agreement
does
not
specify
where
the
walcker
can
can
be.
C
There
is
no
explicit
definition
of
what
are
the
search
patterns
that
can
be
used
with
each
object
type
search.
So
perhaps
we
need
to
define
those
so
that
we
can
have
interoperability
in
the
searches.
And
finally,
this
is
not
really
coming
from
the
the
temp
spec
but
I
sort
of
remember
that
I
think
Scott
of
maybe
others
mentioned,
and
also
this
may
be.
Given
the
the
recent
discussion
about
internationalization
just
before
this
session.
C
Maybe
we
need
to
check
that
we
have
proper
a
covering
of
the
internationalization
in
regards
to
search
since
this
these
searches
could
happen
in,
for
example,
entity
names.
Then
we're
talking
about
Unicode,
so
we
may
need
to
look
into
this
I'm,
certainly
not
an
expert
on
and
not
that's.
Why
I
put
a
question
mark?
Maybe
we
need
to
look
at
this
and
not
sure
about
it
and
I
think
that's
that's!
It
I
had
another
slide
about
the
the
privacy
requirements,
but
I
don't
think
these
are
really
important
for
these
discussions.
G
G
At
the
point,
this
was
some
of
the
last
stuff
that
actually
made
it
into
the
document
and
I
think
we
were
all
looking
more
to
just
kind
of
declare
a
victory
and
move
on,
knowing
that
what
was
there
was
a
hack
and
that
we
would
need
to
get
back
at
it
and
look
at
it
at
some
point
in
the
future.
I
would
not
be
a
fan
of
trying
to
add
text
that
says
hey.
G
Any
of
you
who
are
familiar
with
you
know:
unix-like
operating
systems
understand
how
regular
expressions
work
and
they
get
us
everything
there
in
terms
of
those
first,
three
bullets
and
more
now,
the
syntax
is
a
little
bit
more
complicated.
You
know
for
the
novice
who
doesn't
understand
what
regular
expressions
are,
but
this
is
where
software
interfaces
can
be
very
helpful
right.
It's
some
of
the
right
code
that
abstracts
away
some
of
that
complexity
and
makes
it
easier
for
humans
to
construct
search
patterns.
G
G
The
problem
with
bullet
number
four
is
that
74
82
does
not
give
us
any
type
of
query
paths
that
let
us
dig
deeper
into
like
the
sub-elements
of
contacts.
If
there
truly
is
a
requirement
to
be
able
to
do
things
like
searches
based
on
zip
code
or
reverse
searches,
like
you
know,
hey
here's,
a
contact,
ID
tell
me
all
the
domain
names
associated
with
it.
We
need
another
specification
for
that.
It's
it's
just
not
there,
and
neither
of
those
are
included
in
that
regex
draft
that
I
just
described
a
moment
ago,
internationalization
improvements.
G
Definitely
this
is
definitely
something
we
need
to
think
about,
and
it
I
mean,
maybe
not
even
us,
think
about
it,
but
like
those
of
you
who
are
in
the
internationalization
review
Boff
a
little
while
ago,
what
I
was
thinking
while
they
were
asking
for
volunteers.
Look
I'm
no
expert
here,
but
I'm
expert
enough
to
know
when
I
don't
know
what
I'm
talking
about
and
when
to
ask
for
help.
G
This
may
be
a
place
where
we
ask
for
help
and
remember
now:
John
cleansin,
you
know
one
of
the
folks
that
was
in
that
room
did
help
us
a
bit
as
we
were
looking
at.
You
know
some
of
these
concepts,
the
internationalization
stuff,
that's
in
74
82
is
largely
there
with
the
input
of
folks
like
John,
Paul,
Hoffman,
Patrick,
falserum
and
other
clue,
'full
people,
but
still,
if
we
need
to
think
about
this,
we
need
to
leverage
that
expertise.
H
H
So
in
it
yeah,
but
there's
a
statement
in
the
earlier
slide
that
says
that
the
temporary
specification
requires
a
bunch
of
search
criteria.
1.2
says
that
if
search
capability,
where
search
capabilities
are
permitted
and
offered
the
Registrar,
the
the
provider
must
ensure
that
the
search
is
in
compliance
with
applicable
privacy
laws
and
only
permit
searches
on
data
otherwise
available
to
the
user,
and
so
there's
nothing
that
talks
about
binary
operators
or
and/or
or
what
wildcards
or
anything
like
that.
H
So
they
will
need
to
cross
up
because
I,
just
don't
I'm,
not
saying
because
the
implication
here.
Sorry,
because
the
implication
in
the
in
the
slides
leading
up
to
this
was
that
oh
there's
requirements
that
are
coming
from
a
policy
body.
This
is
we
have
to
do
search
ergo.
We
need
to
standardize
something
here,
but
that's
not
the
I'm
stating
that
that
I'm
not
seeing
the
policy
lever.
That's
driving
that
technical
standardization.
D
So
Jim,
Galvin
and
I
guess
in
response
to
your
Rick
I,
guess
the
way
that
I
had
interpreted
what's
there.
So
this
becomes
a
point
of
discussion.
This
is
not
the
right
group
for
this
continued
discussion
is
I
interpret
us
to
say
that
if
you're
currently
doing
search
and
who
is
then
you
now
have
to
do
the
same
thing
in
our
DAP
and
they
simply
added
a
couple
of
extra
requirements
there.
But
you
know
that's
something
to
a
different
interpretation,
and
this
is
not
the
right
forum
for
all
of
that
and
I.
H
D
N
Any
new
Naren,
so
we
have
kind
of
a
form
of
this
in
our
who
is
art
of
US
service,
which
kind
of
predates
our
debt,
but
we
still
have
it
and
has
it
every
time
I've
ever
seen
it
used
when
I
look
at
what
people
are
doing
there.
It's
about
data
mining
people
are
trying
to
mine.
Our
data
using
these
facilities,
so
I
would
I
would
caution
that
that's
maybe
one
of
the
avenues
that
this
thing
will
get
abused
for
not
trying
to
dissuade
anyone
from
working
on
this
by
all
means.
N
If
you
think
this
is
a
good
idea,
go
ahead
and
go
for
it,
but
you
may
want
to
consider
also
looking
at
some
sort
of
authentication
mechanisms.
Scott
puppy
has
a
draft
on
it.
That
goes
along
with
this.
The
other
thing
I
would
like
to
say
is
this
is
very
complex,
and
so,
if
this
working
group
is
going
to
proceed
with
something
like
this
I
think
that
we
need
to
think
about
some
sort
of
structure
where
we
can
do
rapid
iteration
on
implementations
before
trying
to
get
an
RFC.
M
N
Gonna
do
is
you're
gonna,
have
people
implement
multiple
things
and
you're
gonna
find
out
pretty
quickly
that
there
was
a
difference
between
people,
read
documents
differently
and
they're
going
to
come
up
with
some
very
interesting
ways
of
interpreting
that
and
they're
not
going
to
be
compatible.
So
you
want
some
rapid
iteration
when
it
comes
to
implementations
before
trying
to
get
final
ink
on
an
RFC.
N
C
Given
the
recent
changes
in
in
the
utility
space,
anonymous
user
will
not
be
able
to
do
that
because
they
will
otherwise
don't
have
will
not
have
access
to
that
data.
Well,
I
should
not
say
no
cases
in
in
many
cases,
and
let's
leave
it
at
that.
The
point
is
you
will
only
get
access
to
the
data
that
you
will
otherwise
get
access
to
and
a
you
can
only
use
a
data
for
quayne
that
you,
you
will
otherwise
have
access
to
in.
N
D
D
So
Jim
Galvin,
no
hats,
you
know
I
I
guess
when
we
started
talking
about
searching
I,
think
had
all
kinds
of
things
that
I
wanted
to
say,
but
maybe
I'll
just
frame
it
in
the
following
way,
which
is
I,
really
want
to
understand
what
problem
we're
solving
by
doing
this
I
think
Andy
started
to
touch
on
this
too.
You
know.
D
One
of
the
reasons
why
you
you
have
searching
is
because
people
are
just
trying
to
get
access
to
things
for
all
kinds
of
bulk
access
reasons
and
and
other
kind
of
obscure
things
and
and
I
just
generally
have
the
view
that
there
are
better
solutions
to
that
problem
than
providing
searching.
I've,
always
thought.
So,
let's
see
separating
technical
discussions
from
policy
discussions,
I've
always
thought
that,
from
a
policy
point
of
view,
the
requirements
for
searching
we're
not
quite
right
and
without
getting
into
details
here.
D
The
other
side
of
it
is
getting
back
to
what
Scott
and
others
have
said
here
along
the
way.
You
know
the
searching
capabilities,
the
stuff
gets
really
complicated.
I
mean
I,
get
that
there
are
tools
that
help
some
of
this.
But
you
know
once
you
throw
internationalization
into
the
mix
all
kinds
of
interesting
things
happen
to
you
when
it
comes
to
fuzzy
matching.
You
know
when
you've
got
multi
code
point
characters
and
how
you
match
them
or
don't
match
them,
and
I'm
really
kind
of
nervous
about
all
that.
D
So
I
see
us
having
a
lot
of
discussion
about
what
problem
we're
solving
before
we
decide
what
we
technically
want
to
propose
for
searching
and
I
just
wanted
to
put
that
out
there
for
people
to
think
about
I'd
rather
see
us
shrink
and
and
bit
further
constrain.
What
searching
is
allowed
then
tried
to
expand
it
personally.
Thanks.
F
This
Roger
and
I'll
just
add
not
just
complicated
but
resource
intensive.
When
you
start
searching
the
amount
of
resources
it
takes
is
insane,
but
along
that
to
answer
Rick's
question
I
didn't
catch
it,
but
then
I
kind
of
pulled
it
back.
In
my
mind
what
francisco
said
on
those
list
of
requirements,
number
one
was
in
the
temp
spec
and
the
rest
of
them
were
in
the
contract
and
it
does
I
think
going
back
to
what
Jim
said
it's
based
on.
If
you
have
to
do
searching,
then
those
rules
apply.
F
D
If
I
may
just
just
build
on
that,
that's
that's
actually
a
really
good
point,
especially
as
we
move
in
a
new
direction
here,
if
maybe
our
depth
with
registrar's,
we're
gonna
have
an
inconsistency
here,
but
that's
a
policy
issue,
not
a
technical
issue.
So
we've
got
to
be
careful
that
separate
that
discussion
in
this
room,
so
swatch.
I
Sense
implement
fillets
on
Edition
under
piracy,
I
think
my
view.
If
you
have
piracy
issue
you
only
not
only
you
have
to
have
access
right
for
the
data
that
you
can
access
and
you
can
only
to
do
accept
what
you're
looking
for.
So
my
opponent
will
providing
any
searching
while
sort
of
whatever
matching
is
is
violating
the
piracy,
because
if
you
know
what
you're
looking
for
you
should
just
look
for
exact
match
and
having
any
search,
meaning
that
you
are
just
taking
into
other
people
piracy.
I
C
This
is
Francisco
Reyes
on
that
River
for
those
interested
in
in
Italy
policy.
There
is
four
that
is,
and
you
probably
know
already
what's
on
the
EPD
P
that
is
going
to
work
on
reviewing
this.
This
temporary
suspect
it's
probably
a
good
place
to
trace
these
issues
so
that,
if
you
have
some
concerns
about
this
type
of
service,
I
think
that's
the
the
right
place
to
where
you
can
feed
those.
So
they
can
take
it
into
account
to
limit
what
can
be
done
in
in
searches.
D
So
and
Jim
wanting
to
channel
Jody
from
the
jabber
room
here
he
said
Jody
Coker,
he
says
I
have
concerns
with
how
many
domains
will
be
returned
if
a
search
is
for
the
street
address
that
is
used
for
privacy,
millions
of
domains
would
be
returned.
That
will
be.
That
will
add
to
the
complication
of
this
implementation
and
and
I
think
you
know
now
reverting
to
myself
and
speaking
personally
and
building
on
this.
This
really
is
the
question
that
I
have.
D
What
problem
are
we
solving
before
we
get
into
talking
about
what
kind
of
searching
we
think
ought
to
be
supported
and
ought
to
be?
There
I
really
want
to
step
back
and
ask
ourselves
what
problem
are
we
solving,
and
what
are
we
trying
to
achieve
here?
Because
there
are
just
so
many
issues
and
with
the
new
privacy
requirements
it
just
I'm
challenged
by
trying
to
imagine
how
searching
is
valuable,
because
if
you're
really
looking
for
bulk
access,
there's
better
ways
to
do
that,
we
should
be
talking
about
something
different,
not
not
searching
anyway,
thanks
Scott.
G
Hollenbeck
now
ignoring
the
meta
question,
you
just
raised
Jim,
okay,
that
that's
a
long
topic,
but
the
question
of
how
to
control
what
gets
returned.
Mari
hola,
Fredo,
Mauricio
and
I
have
authored
a
draft
that
just
that
gives
clients
some
capability
for
requesting
that
the
server
you
know,
sort
and
page
responses.
G
Yeah
I
mean
it's
still,
not
something
I'd
necessarily
want
to
implement
in
terms
of
returning
10
million
results
back
to
a
client,
but
the
technology
certainly
exists,
and
if
we
are
inclined
to
apply
that
to
solve
a
particular
problem,
you
know
getting
back
to
your.
What
problem
are
we
solving
question?
We
do
have
some
options
to
consider.
N
And
engineering,
so
so
I
just
want
to
clarify
the
the
I
can't
actually
imagine
there
are
legitimate
uses
to
the
for
this
I
I
can
think
of
a
lot
of
I.
Just
think
that
it's
also
ripe
for
abuse
and
that's
why
I
made
that
comment
like
I
said:
if
people
want
to
do
this,
I
think
they
should
be
allowed
to
do
this,
but
I
think
the
question.
It
is
a
very
good,
very
good
thing
to
ask
the
question:
what
exactly
are
we
trying
to
do
here,
because
there
may
be
better
ways?
N
L
Just
a
quick
comment:
you
know
when
you're
first
temporary
specification,
I'm
sure
everybody
knows
that
the
ugly
four
letters,
but
you
know
the
the
things
may
roll
over
time.
So
we
must
be
ready
for
you
know.
What's
coming
next,
because
the
post
temporary
the
post,
gdpr
I,
can
approach
to
the
data
and
I
don't
want
to
bring
this
up
just
what
just
to
know
that
mentally.
We
should
be
pretty
for
that
down
the
road
thinking,
yeah.
D
D
So
there's
there's
a
lot
of
moving
parts
going
on
right
now,
I
think
what
we
do
need
to
think
about
and
I
guess.
Maybe
the
question
is
to
you
Francisco
on
this
particular
point
here
is:
are
you
interested
in
bringing
to
this
group
a
desire
to
to
make
this
a
work
item
talking
about
searching
the
work
item?
And
you
don't
have
to
answer
that
right
now,
because
we're
gonna
have
a
working
group
meeting
tomorrow
and
so
well.
D
Alright,
there's
no
other
question
about
anything.
The
other
guy,
James
or
Roger
I
mean
you
had
your
two
presentations,
any
closing
comments
from
you
on
on
your
work
or
documents
Burke
right
now
and
anybody
else
have
anything
they
want
to
add.
Then
we'll
just
declare
this
particular
working
session
adjourned.
I
very
much
appreciate
the
three
guys
who
came
quite
prepared
and
we
had
a
really
good
discussion.
I
think
that's
excellent!
Tomorrow
we
have
just
a
one-hour
meeting,
but
it
is
a
full.
You
know.
Relatively
formal
working
group
meeting
will
walk
through
status
of
documents.
D
Talk
about
next
steps
where
we
are
are
things
the
Charter
and
stuff
like
that,
and
you
know,
do
our
plans
for
what's
to
come
here
in
the
near
term
in
the
long
term.
So
with
that
have
a
good
night.
Everybody
see
you
tomorrow,
Oh
blue
sheets.
Where
are
they
I
see
the
one
up
front,
where's
the
one
in
the
back,
just
hold
it
up,
please,
and
if
you
haven't
signed
it,
please
find
one:
oh
I
see
them
now.
Okay,
thanks
very
much
thanks
for
the
remote
attendees.