►
From YouTube: IETF100-REGEXT-20171113-1330
Description
REGEXT meeting session at IETF100
2017/11/13 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
C
D
A
A
A
E
Got
a
very
fun
very
pointed
question:
I
wanted
to
ask
someone
like
yourself
yeah,
even
if
you're,
not
the
right
person,
I
know
you
can
find
something.
So
when
we
talk
about
gated
accidents
right
and
this
idea
of,
if
you're
willing
to
talk
to
indicate
yourself,
you
will
be
able
to
get
some
type
of
access
to
more
information.
E
E
A
B
A
F
E
E
A
A
G
G
H
D
Have
those
and
I'm
sure
this
with
us
vehicle
road,
so
he's
a
remote
chair
here
see
slide,
obviously
the
oldest
or
the
first
made
up
as
usual
just
eating
today
you
say
your
do
belongs
the
idea.
Please
say
no
to
that
question
certain
certain
enemy,
this
you
are
urged
to
speak
to
your
own
people,
represented
duty
and
make
decisions
about
what
you
aren't
going
to
do
within
the
idea.
D
There
was
a
time
and
a
lot
of
work
reduce
to
focus
up
I
like
to
still
continue
to
use
this
working
group
that's
be
somewhat
slow,
moving
their
writing
reasons,
one
of
which
is
just
making
sure
that
we
have
people
who
perfu
documents
and
that
could
be
engaged
in
their
discussions
so
like
to
slide
up
their
mind.
People
pens
do
that
those
documents,
so
it
is
useful
to
be
somewhat
obvious,
I
suppose,
which
is
that
you
want
your
documents.
D
D
I
D
D
D
D
D
D
There
give
us
these
slides
that
he
had,
but
one
can
talk
about
these
things.
He
included
that
that
slide
it
there
I
just
figured
like
it's
zero
minute,
give
a
little
bit
of
an
introduction,
as
he
gets
up
to
the
microphone
here
to
talk
about
his
is
to
updates.
You
also
give
us
the
league
in
or
a
ways
that
we
talked
about
at
the
working
session,
yet
so
bright
curve
up
here,
Judy
and
I
think.
H
A
D
J
Thanks,
hopefully,
this
is
loud
enough
online
as
well.
The
feed
IQ
met
I
think
we're
there.
We've
got
a
couple
open
questions
that
we've
popped
up
from
implementation,
actually,
which
is
great.
The
next
version
is
ready
to
be
published.
It
hasn't
been
published
yet,
where
I
think
it's
still
a
8th
online
right
now,
revision,
9
I,
actually
just
added
one
extra
item
to
the
schema
so
that
the
server
client
and
server
can
have
better
type
checking
on
the
epp.
So
that's
the
only
change.
J
Besides
clarity,
a
lot
of
implementation
that
work
has
been
done
and
a
lot
of
clarity
items
have
been
added
in
just
text.
The
two
questions
that
came
up
I,
don't
know
if
Jim
wants
to
talk
to
him
directly
but
I'll
raise
him
here.
He
talks
about
the
CD
fail
flag
and
what
that
means,
if
a
partial
return
is
done.
So
if
you're,
only
returning
a
partial
set
of
the
requested
commands
from
the
client,
what
should
the
CD
avail
flag
be
set
to
and
right
now,
my
interpretation
of
document
is
that
it
would
return
0.
L
Yeah,
the
steam
cooled
from
Verisign,
so
I
actually
had
the
opposite
thought
on
that.
One
I
thought
that
if
L
thought
I
actually
won,
if
all
of
the
fee
information
was
there
and
zero.
Otherwise.
So
and
the
reason
why
I'm
saying
this
is
that
if
it
was
zero,
I
was
feeling
that
for
the
fast-fill
scenario
that
then
the
reason
would
be
required
and
then
otherwise
it
would
not.
So
that's.
L
Was
the
second
part
yeah?
So
if
it
was
a
partial
fail
scenario
that
you
could
use,
the
single
reason
define
why
you're
not
including
all
of
it
or
you
would
have
the
reason
under
each
of
the
commands
itself,
which,
when
I,
was
doing
the
implementation
in
the
in
our
SDK.
That
I
thought
it
was
overly
complex
to
figure
out
like
what
how
the
client
would
actually
process
either
a
fast.
J
Fail
or
a
partial
fail,
so
I
assumed
from
early
on
in
discussions
that
registries
would
pick
one
or
the
other
most
likely
so
ones.
Gonna
return
a
fast
fail
and
not
return
anything
where
other
registries
will
actually
try
to
process
what
they
have
and
return
that
data.
Knowing
that
you
know
some
data
is
going
to
be
missing.
So
that's
why
I
said
the
zero
still
works,
because
it's
didn't
complete
the
command
it.
It
actually
failed
part
of
the
command.
L
I
think
having
the
two
reasons
is
somewhat
of
a
confusion
as
well
I'm
thinking
that
if
it
was
zero
that
you
would
include
an
overall
reason,
why
it's
not
it
well,
if
you
said
zero,
they
would
return
a
reason
why
you
could
not
provide
it.
So,
as
I
said,
I
think
there
were
two
different
scenarios
and
I
think
that
we've
had
some
discussions
on
it
offline.
So,
okay,
I'm.
L
Yeah
one
item
that
came
on
the
list
that
I
wanted
to
be
a
clarification
on
was
associated
with
the
classification,
because
the
the
text
in
the
graph
says
classifications
associated
with
the
object
and
I
know
that
there
was
Prior
discussion
on
the
list
that
there
was
a
question
who's
associated
with
classification
since
the
classifications
on
the
command,
not
at
the
object
level
in
the
in
the
XML
schema.
But
I
believe
I
would
like
to
hear
from
the
other
registries
as
well.
Is
that
I
believe
that
the
classification
is
truly
at
the
object
level?
L
So
if
it's
a
premium
domain
name,
the
fees
are
associated
with
the
fact
that
is
a
premium
domain
name
and
that
if
it
happens
that
the
renew
price
was
the
same
for
a
standard
and
a
premium
name
that
you
wouldn't
switch.
The
classification
based
on
the
command
asked
for
it
was
renew
it's
at
the
object
level.
So
my
proposal
would
be
moved.
Classification
up
to
under
the
CD
element
is
instead
of
at
the
command
level
layer,
yeah.
J
And
I
think
this
we
did
have
this
discussion.
I,
don't
know
if
a
song
list
or
off
list
but
yeah.
That
was
a
discussion
that
was
had
and-
and
it
does
make
sense
to
me
as
well-
that
it's
at
the
object
level
at
the
domain
level
so
that
it
should
be
moved
up
to
that
level
again.
If
other
registries
have
different
thoughts,
let
us
know
I'll
post
that
to
the
list
as
well.
J
So,
okay,
any
other
questions
or
comments
on
the
fee
document,
all
right,
I'll
go
ahead
and
post
those
last
two
remaining
items
to
the
list:
publish
the
next
version
shortly
after
the
Hat
I'll,
give
time
for
comments,
of
course,
but
and
then
actually
I'll
ask
for
working
group
last
call
up
with
that
version.
So.
F
D
J
Typically
right
guys
should
say
today
if
you
can
create
valid
contacts
that
on
their
own
are
okay,
but
when
you
actually
do
a
domain,
create
and
assign
them
to
a
role,
registrant
admin
or
whatever
additional
checking,
is
done
at
that
time
and
will
fail
the
registration.
So
the
goal
of
this
extension
is
to
actually
provide
a
way
to
validate
those
contacts
before
actually
trying
to
do
a
domain
create.
J
L
Yes,
team
gold
from
Verisign
Irie
reviewed
it
this
morning.
I
know
that
we've
had
some
prior
discussions
on
this,
but
when
I
was
having
gifts,
some
questions
about
was,
it
looks
like
he's
passing
all
the
contact
data
to
validate
in
essence,
in
preparation
for
Navy
a
contact
create,
even
though
it
looks
like
you're
trying
to
prepare
for
a
domain
create
so
part
of
it
is
like
whether
or
not
you
could
use
this
for
existing
contacts
as
well.
L
As
you
know,
in
preparation
to
create
contacts
so
that
if
you
had
a
way
an
implementer
would
say
well
am
I
supposed
to
look
to
see
whether
or
not
the
contact
information
linked
to
that
contact.
Identifier
is
valid
for
this
particular
domain
name
or
TLD.
It's
not
clear
in
the
draft
whether
or
not
you're
doing
it
for
existing
contacts
or
new
contacts.
I
know
there's
a
working
session
on
this
later
on.
L
J
Thanks
Jim
and
actually
its
intended
for
any
contact,
so
new
or
existing
contacts,
its
intended
for
and
the
goal
was
the
domain
create,
though,
obviously
you
can
be
used
for
the
contact
create
as
well,
but
the
goal
was
originally
so
that
once
the
domain
create
came
up
there,
there
wouldn't
be
a
chance
of
lesser
chance
of
a
failure.
So.
J
Okay,
yeah
and
we
will
talk
about
it
in
the
working
session.
Briefly
again,
there
hasn't
been
a
whole
lot
of
comments
on
it.
It
is
something
that
we
actually
run
into
every
day,
we'll
we'll
be
able
to
create
our
for
contacts
perfectly
fine
at
the
registry
and
then
go
to
do
a
domain
crate,
and
it
fails
so
and
it
happens
multiple
times
a
day
for
us.
So
it's
a
big
issue
and
I
think
that
was
it.
J
Thanks
you're,
so
registry
mapping,
I,
think
I
think
it
came
up
last
ETF
or
maybe
one
before
that,
where
we
were
started
talking
about
the
correct
place
for
defining
some
of
the
launch
phase
attributes
and
we
decided
that
the
feed
document
wasn't
correct.
We
decided
that
the
launch
phase
document
wasn't
correct,
so
we
started
looking
here
and
then
we
realized
actually
this.
This
solves
maybe
some
other
problems
that
I
exist
out
there
today
and
again.
D
That
been
part
of
meeting
materials
till
just
before
this
meeting
that
fortunately
only
upload
at
least
you
slides
from
before,
but
I
took
the
Excel
spreadsheet
that
he
gave
us
and
turned
into
eeeh.
It's
not
a
pretty
idea.
You've
ever
done
themselves
perfect,
it's
not
pretty!
Unless
you
actually
bothered
to
figure
out
how
to
format
it.
D
I
took
the
easy
way
out
the
purposes
of
just
getting
the
document
out
there
for
equal
when
I
grabbed
it,
but
if
folks
have
Excel
and
you
actually
want
the
actual
document
I'm
sure
when
we
get
into
the
working
session,
you'll
distribute
it
around
whoever's
there
and
wants
to
see
it
so,
but
the
meeting
materials,
don't
let
you
upload
excel
documents
anyway.
That's
why
I
didn't
upload
that
directly.
You
have
to
make
it
a
PDF,
they'll,
take
powerpoints
and
Docs
and
text
files,
and
that's
it
so.
Okay,
I,
don't
see
anyone
coming
to
the
mic.
D
Okay,
that
brings
us
to
the
next
section
where
we
want
to
just
kind
of
go
through
and
review.
Some
of
our
milestones.
I'm
gonna
try
to
do
a
little
bit
of
a
tag-team
here
with
with
Antoine,
so
maybe
Antoine.
If
you
want
to
jump
into
the
queue
here
and
then
I'll
I'll
open
it
up,
so
that
you
can,
we
can
see
if
you
can
speak
and
we
can
hear
you
hi
everybody
there
we
go.
Alright!
Oh
that's
right!
I
forgot!
D
He
was
explaining
to
me
once
before
that
as
the
remote
chair,
you
get
a
different
kind
of
login,
so
he
can
just
talk.
He
doesn't
actually
have
to
be
approved
to
talk
with
the
cue
okay
so
just
to
set
up
this
discussion
a
little
bit.
One
of
the
things
to
mention
folks
will
recall
from
earlier
this
year.
In
the
first
meeting
of
the
year,
we
had
a
desire
to
want
to
add
some
additional
documents
actually
was
a
year
ago.
It
wasn't
even
March,
it
was
the
fall
meeting.
D
Last
year
we
had
a
document
in
particular
from
Scott
and
and
went
from
Andy.
So
there
was
a
desire
to
add
some
new
working
documents
to
our
agenda,
our
list
of
milestones,
and
we
got
some
pushback
from
our
AIRAID
director
to
you
know
to
clean
up
our
milestone
list
and
to
move
our
documents
along
a
little
more
smartly.
He
didn't
want
us
adding
additional
documents
until
we
kind
of
cleaned
up
where
we
were
now
along
the
way
we
we
have
actually
cleaned
things
up.
We
have
moved
a
lot.
D
We've
gotten
rid
of
a
couple
of
documents
and
and
sort
of
set
them
aside
and
move
them
off.
Launch
base
is
obviously
being
published
and
we
have
a
number
of
documents
which
are
very
close
to
being
published
all
but
published.
In
fact,
I
made
a
assertion
to
our
area
director
yesterday
in
a
brief
discussion
with
him
about
this,
that
we
are
pretty
close
to
three
to
five
documents
being
ready
to
be
pushed
up
for
IHG
publication.
You
know
by
the
end
of
this
calendar
year
or
certainly
given
the
holidays.
D
But
as
part
of
that,
it
seems
useful
to
take
a
hard
look
at
some
of
the
documents
that
are
there
and
really
confirm
that
these
things
are
ready
to
be
pushed
out
the
door
or
not,
or
what
the
specific
actions
are,
because
we
have
a
number
of
documents
that
just
kind
of
are
waiting
in
part
for
reviews
and
part
for
implementation
issues.
You
know
we
just
need
to
decide
if
we're
going
to
release
these
or
what
we're
holding
the
back
for,
in
particular.
D
So
with
that
is
the
setup
will
kind
of
take
these
things
one
at
a
time.
Antoine
is
going
to
jump
in
and
talk
about
each
document,
as
we
go
along
here
say
with
these
documents,
what
their
status
is
from
the
chairs
point
of
view
and
then
we'll
look
for
comments
or
questions
from
anyone
in
the
room
about
the
documents.
So
we
can
decide,
you
know
what
we
really
think
our
next
step
is
and
the
first
one
up
here
is
the
change
poll
document
so
Antoine
over
to
you.
Yes,.
M
A
M
C
L
It's
Jim
gold
from
Verisign,
so
yeah
I
can
go
ahead
and
talk
to
both
the
change
poll
and
the
allocation
token.
The
action
item
from
the
last
working
group
session
was
to
add
the
implementation
information
that
Cal
added
for
both
drafts.
So
now
we
have
implementation
status,
information
from
new
star
and
Verisign
for
both
these
drafts
and
we
feel
like
it's
ready
both.
O
L
M
D
M
D
Yeah,
just
to
emphasize
that
point,
Antoine
and
I
have
talked
about
this,
and
you
know
I
in
in
this
group
in
particular,
we'd
really
very
much
like
to
have.
You
know
three
to
five
people
who
acknowledge
that
a
document
should
move
forward
who
are
not
the
authors
of
the
document,
which
can
make
things
a
little
interesting
for
us,
sometimes
because
there
aren't
that
many
people
who
keep
up
with
all
of
the
documents.
That's
why
we
say
three
to
five,
but
you
know
please
says,
as
always,
you
know.
D
Even
if
you
don't
have
any
comments,
please
do
take
a
look
at
something
and
indicate
your
support
for
moving
it
forward,
just
so
that
we
know
that
we
have
some
sense
of
consensus
from
the
working
group
on
the
mailing
list.
The
usual
IETF
way
of
doing
that
is
just
sending
a
plus-one
when
someone
asks
for
a
support
for
a
document
as
your
message
body.
So
please
just
keep
that
in
mind.
M
M
I've
requested
some
changes
that
I
still
need
to
verify
they
they,
if
the
text
was,
was
correct,
but
I
think
this
one
is
one
that
will
stay
in
the
queue
the
the
deadline
is
not
there
yet,
but
I
think
it.
The
only
thing
it
needs
is
some
more
specific
review
apart
from
the
authors,
and
if
that
assessment
is
correct
or
not
correct,
I
would
like
that
here
to
hear
it
from
the
room.
L
Yes,
you
can
go
from
Verisign
yeah,
so
I
did
a
recent
review
of
this
draft
and
I
have
a
concern
related
to
the
fact
that
the
trust
relationship
between
the
DNS
operator-
and
in
this
case
the
registry
is
not
addressed
in
this
particular
draft.
I-
think
that's
the
big
problem
here,
because
if
you
did
have
trust
between
the
dns
operator
and
the
registry,
you
just
use
EPP
and
the
existing
DNS
SEC
extension
RFC
5910
to
do
what
needs
to
be
done.
L
D
Yeah
and
I
will,
let
me
put
myself
in
the
queue
and
speaking
as
an
individual,
not
as
as
chair
I
really
do
need
to
agree
with
Jim
golden
on
this
particular
point
for
this
document.
I
appreciate
that
the
document
works.
Certainly,
we
have
Jacques
Latour
from
from
Serie
as
a
ccTLD
is
actively
working
on
this
and
built
an
implementation.
I
believe
the
folks
from
the
Czech
Republic
are
doing
it
too,
so
I
think
they
actually
do
have
two
implementations
of
it.
D
The
you
know
it.
It
really
is
interesting
in
that
it
works
in
that
context,
but
it
really
is
an
issue
for
gTLDs
for
exactly
the
reason
that
Jim
Gould
was
pointing
at
so
you
know
it's
difficult
I
know
for
me
to
support
this
document
and
I
think
without
not
trying
to
put
too
many
words
and
in
Jim's
mouth
from
Verisign,
but
he's
saying
the
same
thing
he's
just
sort
of
in
an
awkward
place.
I,
don't
see
us
being
an
implementer
of
this
document
and
that'll
be
kind
of
an
issue.
J
We
hi
this
Roger
yeah.
Besides
the
I
mean
the
document
does
come
out
and
say
we're
not
going
to
talk
about
this
in
the
document
which
yeah
I
think
is
an
issue.
The
other
big
issue
that
we
have
as
a
registrar
is
when
registrar
customer
information
gets
changed
outside
of
the
registrar
loop.
It
becomes
an
issue
and
I
know
that
this
draft
tries
to
do
that.
J
There
tries
to
handle
it
by
saying
it
can
be
done
by
registry
or
registrar,
but
the
big
issue
is:
is
communication
back
to
the
registrar
so
that
they
have
the
most
current
information,
because
we
will
be
the
one
speaking
to
the
registrar
when
something
goes
wrong.
So
it's
one
of
the
facts
that
yes,
the
the
security
issue
is
big,
but
the
I
also
think
that
that
loop
has
to
be
figured
out
as
well
as
how
does
that
get
communicated
all
the
way
through
the
chain
appropriately
and
as
Jim
mentioned,
I.
J
D
So
we
actually
don't
have
the
authors
of
this
draft
in
the
in
the
room
here
or
listening
to
this
discussion.
I
know
that
they've
heard
this
kind
of
message
before
so
I
think
you
know.
Perhaps
this
is
more
of
a
heads-up
from
the
chairs
to
the
working
group
that
the
milestone
for
this
document
is
coming
up.
It's
in
the
future.
It's
not
in
November.
It's
it's
early
in
2018.
D
You
know
I'm
sure
we're
going
to
get.
You
know
pressed
at
some
point
here
and
what
to
do
with
this
document
and
I
think
the
working
group
is
going
to
have
to
come
to
a
consensus
about
whether
we're
going
to
keep
this
on
our
to-do
list,
or
you
know,
set
it
aside
for
not
being
standards
track
and
let
these
guys
submit
it
as
their
own
informational
document
and
just
put
it
in
the
extension
registry
in
Ayana
as
an
individual
contribution,
might
be
the
way
to
go.
D
A
A
C
M
M
Some
others,
too
are
doing
bundling
at
the
moment.
So
there
is
justification
for
documenting
this,
but
we
believe
this
will
not
be
a
one
standard
fits
all.
So
a
suggestion
is
to
make
this
document
informational
and
then
just
register
the
registry,
and
we
can
move
it
off
our
list
in
that
way,
unless
variant.
Of
course,
objection
to
that-
and
this
is
the
standard
way
of
doing
these-
so
is
there
any
discussion
in
the
room?
Are
there
any
other.
R
C
R
M
D
Okay
I
think
he
was
going
to
the
statement
that
he
was
going
to
make.
Is
it's
partly
about
the
status
of
the
document?
It
may
be
that
this
is
not
appropriate
for
a
standard
strike
doctrine,
which
is
really
the
question
for
us
to
think
about.
Now
we
have
a
queue
lining
up,
so
let's
just
run
through
the
queue
you
can
stay
here
and
then
we'll
get
the
comments
so
Scott
sure.
E
Scott
on
back
one
thing,
I'd
like
to
see
if
we
do
decide
to
take
this
to
information,
was
the
addition
of
an
implementation
status
section
if
the
document
is
intended
to
describe
information
about
an
existing
implementation,
let's
put
that
text
into
the
document
and
describe
your
experiment,
your
experience
in
implementing
it,
and
if
you
know
of
others
who
have
implemented
it,
add
that
to
the
text
as
well.
Please.
B
D
B
Lincoln
one
of
another
author
of
this
internet
draft
and
I
have
a
question
for
Antoine
I'm,
just
wondering
what
kind
of
other
use
case
you
can
mentioned
about
the
pendulum
for
us.
We
try
not
only
provide
provider,
informational
suggestion
for
the
bundling
requirements.
Mostly,
we
focus
on
the
idea
burns,
but
we
do
know
there
are
some
kind
of
other
been
dueling
requirements
from
non-ideal
burns,
but
I
think
our
math
ism
or
our
technically
solution
can
could
be
flexible
to
me
to
meet
any
other
use
cases.
B
B
M
To
respond
to
that
I
believe
there
is
discussion
going
on
later
in
this
session
about
some
DNA
issues
that
came
up
I,
don't
know.
If
that's
another
use
case.
The
only
thing
I
know
is
that
we
couldn't
agree
during
the
bundling
buff,
which
sort
of
bundling
DNS
wise
is
actually
the
you
know
the
one-size-fits-all
way
of
doing
bundling,
and
that
says
to
me
that
at
the
moment
there
is
no
clear
consensus
yet
about
a
one-size-fits-all
bundling
solution,
and
that
makes
me
wonder
you
know.
Perhaps
there
are
no
other
abundant
solutions
coming
up
in
the
future.
M
But
as
long
as
we
don't
agree,
we
don't
have
consensus
that
this
is
the
only
way
that
will
work.
I,
don't
think
it
should
be
a
standard
well
and-
and
that
doesn't
that
doesn't
there's
no
judgment
on
the
legitimacy
of
this
document,
because
I
think
it's
a
good
document.
It
describes
very
well
House
en
ik
is
doing
bundling
at
the
moment
and
I
think
it
should
be
document
it
and
it
should
be
registered
in
registry.
B
I
think
for
the
standard
trike
dropped
layer
that
the
major
change
is
about
what
kind
of
object?
What
kind
of
item
we
need
to
bundle
for
the
registration
level.
So
our
draft
only
talk
about
the
EPP
extension
registration
level,
so
maybe
we
can
have
the
one
set
for
all
handling
registration
for
the
EPP
layer.
If
there
is
is
another
lose
cases,
maybe
not
all
the
object
or
item
want
to
be
banded.
Together
we
can
set
different
items:
different
object
to
be
banned,
or
not
one
by
one.
That's
all:
okay,
okay,.
F
Donation,
do
please
Edmund
come
here
so
building
on
I
guess
what
what
Ning
was
saying
and
I
I
think
in
general,
the
try
I
mentioned
this
in
on
the
mailing
list
as
well.
I
want
to
give
it
another
kick
in
the
can
I
guess
bundling
right
now
we
were
thinking
about
it
as
a
very
general
concept.
The
question
is
whether
it
is
worthwhile.
F
Perhaps
perhaps
one
question
is
whether
it's
worthwhile,
if
it's
just
focus
on
ID
and
variants
as
well,
because
of
the
progress
now,
both
at
ICANN
and
also
at
the
the
LGR,
the
label
generation
rule
sets
which
frames.
What
we
now
can
more
definitely
talk
about
in
terms
of
ID
and
variants,
and
it's
a
big
component
of
EPP
itself
I
mean
it
should
be
ultimately
growing
to
become
a
big
component
of
standard
EPP
transactions.
So
I
think,
besides
just
thinking
about
whether
this
should
you
know
we
push
this
to
information
or
not.
D
L
L
So
in
essence,
if
you
wanted
the
capability
of
allowing
for
variants
to
be
enabled
and
disabled,
then
you
get
into
issues
of
grace
periods
and
and
other
elements
that
are
complex
in
nature,
because
I'm
a
co-author
on
a
different
proprietary
extension
as
well
as
dealt
with
this.
The
other
is
related
to
DNS,
SEC
I,
don't
think
it's
mentioned
in
there,
but
is
there
an
assumption
related
to
use
of
the
key
data
interface
for
DNS
SEC?
D
So,
thank
you.
I'm
gonna,
add
a
comment
and
then
give
the
last
word
to
Antoine,
I.
Think
and
III
would
say
this
discussion
has
been
a
success.
You
know
from
my
point
of
view
as
as
as
chair,
you
know,
we've
been
kind
of
looking
at
this
document
and
wondering
you
know
how
to
go
forward
and
try
to
find
a
way
to
prompt
some
discussion.
I
think
the
critical
question
here
is
standard
versus
informational
and
clearly
we
have
some
questions
about
what
it
means
to
be
standard
and
some
other
things
that
need
to
be
addressed.
D
M
Yeah,
so
for
this
document
in
particular,
I
don't
have
any
more
remarks.
I
really
like
the
discussion.
Indeed,
you
know,
there's
still
the
discussion
of
the
author's
want
to
have
this
as
a
standards
track,
and
there
are
some
others
that
have
at
least
concerns
about
standards
track
the
course
issues
have
not
been
addressed
yet
and
I
think
we
should
continue
that
discussion
on
the
mailing
list.
D
M
Go
ahead,
so
these
are
the
or
documents
they
have
a
date
in
the
well
in
the
future
as
well.
These
are,
of
course,
the
results
of
the
documents
that
first
were
the
reseller
documents
and
there
seem
to
be
quite
some
interest
in
the
reseller
extensions,
but
now
that
they've
turned
into
your
generic
organizational
drafts,
the
interest
has
sort
of
like
slipped
away.
I
think
that
these
documents
needs
another
thorough
review.
At
least
I
need
to
make
another
review
I
know,
but
it
could
also
use
some
implementation
status,
I
think
or
some
intention
of
implementation.
B
Yeah
we
have
being
in
the
nap
box
up
here,
yeah
this
seasoning.
We
are
trying
to
update
our
hog
drafts
and
to
add
implementation.
Staters
section
section-
and
you
know
these
draft
are
changed
from
reseller
draft
and
for
the
reseller
draft.
These
drafts
are
implemented
by
cynic,
NuStar
verasun,
maybe
versa,
and
actually
for
the
open
source
TPP
software,
but
for
the
arc
draft.
B
Now
the
one
really
implemented
it.
But
cynic
is
planning
to
research
on
making
a
demo
of
the
org
draft
and
I'm,
not
sure
we
discuss
with
very
song
guys-
and
you
do
have
interest
in
implementing
the
base
draft
in
future-
and
maybe
not
here-
you
can
correct
me
and
for
this
point,
I
also
want
to
call
for
more
implementation
about
these
hog
draft
and
because
we
have
a
long
discuss
about
the
requirements
from
the
reseller
and
requirement
from
extension
of
organization.
B
L
Jim
go
from
Verisign,
so
I'm
a
co-author
on
these
drafts
and
we
originally
started
with
the
reseller,
which
is
a
little
bit
more
controversial
and
I.
Think
that's
the
reason
why
you're
getting
comments
on
the
list
once
we
went
something
more
generic,
it's
less
controversial,
less
comments.
So
what
I
had
posted
to
the
list
was
a
proposal
to
have
these
graphs
be
implemented
for
what
I've
considered
low-hanging
fruit,
which
would
be
for
our
registrar
information?
L
Verisign
is
built
or
has
created
a
proprietary
extension
that
provides
register
informations
for
transfers.
I
thought
that
this
would
be
a
perfect
opportunity
to
be
able
to
leverage
these
extensions
be
able
to
help
registrar's
in
supporting
transfers
in
a
less
on
a
copy,
that's
less
controversial,
so
I
guess
I
would
be
kind
of
looking
at
Roger
here
from
GoDaddy,
whether
or
not
GoDaddy
would
have
interest
and
be
able
to
support
this
extension
for
providing
registrar
information
for
transfers.
D
So
while
Roger
is
coming
up
to
the
queue
I'll
I'll
step
up
to
the
mic,
so
this
is
Jim
Galvin.
Just
speaking
for
myself
here
and
to
add
on
to
machine
for
Ning
and-
and
you
know,
other
authors
more
generally,
Rogers
about
to
talk
from
I
guess
miss
point
of
view
as
a
registrar.
But
are
there
are
other
significant
gTLDs
outside
of
the
ccTLD
context,
so
registries
that
have
or
will
implement
this
and
are
their
registrar's
to
go
with
them
to
use
it?
D
B
J
This
Roger
again
yeah
I
mean
we
we've
looked
at
this
since
the
beginning,
and
we've
never
found
a
reason
for
us
to
actually
implement
this.
It's
data
that
we're
not
sure
needs
to
be
should
be
I,
guess
shared
across
the
to
third
parties.
I
guess
so
right
now,
I
guess:
Jim
brought
up
a
good
question
on
transfers
and
stuff
doesn't
make
sense.
B
I
think
there
were
repeatedly
discussion
on
the
requirements
of
this
topic
and
from
the
original
period
and
the
reseller
requirement
were
approved
by
the
working
group,
because
we
do
you
have
real
requirement
from
NuStar
one
of
our
proxy
and
who
have
a
lot
of
resellers
and
their
resellers
wanna
show
their
information
on
our
Whois
database
yeah.
That's
the
real
requirement,
but
when
we
do
the
draft
on
this
topic
and
people
discuss
that,
why
not
make
some
general
object
extension
not
only
focus
on
reseller
and
maybe
in
the
future
registrar
and
proxy
privacy.
C
To
move.
I
I
Giving
that
information
through
the
registry
about
our
resellers
is
not
something
that
we
want
to
do
or
will
be
willing
to
do.
We
consider
that
to
be
information
that
that's
just
not
needed
by
the
registry
now
I
know
that
there
isn't
I
can
not
a
requirement,
but
it's
optional
data
to
send
to
the
registry
who
the
reseller
of
record
is,
and
that
is
true
that
this
could
be
used
for
that.
We
just
think
that
this
is
an
overkill
as
far
as
providing
all
information
about
the
reseller.
I
D
Okay,
Thank
You,
Jody,
so
I'll
just
add
a
chairs
comment
and
then
over
to
Antoine
for
the
last
word
here
on
this
I
think
this
this
document
also
falls
into
kind
of
a
similar
category
to
the
DNS
operator
and
even
the
the
bundling
document.
There's
there's
a
real
question
as
to
whether
or
not
it
should
be
a
standard
or
an
informational
document,
and
you
know
a
standard
does
require
you
know
much
more
broad
applicability
and
broad
implementation
is
really
a
requirement
to
be
on
the
standards
track.
D
E
E
S
Any
Newton,
so
I
really
don't
have
a
dog
in
this
fight.
What
really
concerns
me
about
the
conversation
is
you
have
people
saying
I'm
not
going
to
use
it
and
that's
being
turned
into
don't
do
this
and
I
don't
I?
Don't
really
like
that
that
didn't
sit
well
with
me,
some
people,
obviously
we
have
some
interest
in
it
and
if
it's
not
harmful
for
us
to
do
this,
I
don't
see
what
we
shouldn't.
F
S
D
Thank
you
for
that.
I
certainly
am
NOT
trying
to
say
that
it's
bad
I
don't
think
that
Antonia
is
either
I'll.
Let
him
speak
for
himself,
I
actually
haven't
gotten.
A
sense
of
people
are
saying
it's
bad
I
think
people
are
reacting
to
whether
or
not
it
should
be
a
standard
and
to
speak
more
to
add
a
little
bit
elaborate.
A
little
bit
on
Scots
point
I
mean
I
use
the
phrase
broad
applicability.
This
working
group
is
in
sort
of
the
in
odd
place
because
there
are
only
a
few.
You
know.
D
People
who
who
participate
in
this
group
actively,
who
are
what
I
would
call
you
know
an
important
part
of
the
industry
players.
There
are
a
lot
of
interested
parties
here
in
some
of
this
work
and
that's
a
good
thing,
and
we
should
continue
with
that.
But
I
do
find
it
a
challenge
as
as
chair
to
judge
what
consensus
is
and
and
I
try
to
pay
very
careful
attention
to
who
actually
is
in
support
of
something
and
who's,
not
because
it
really
does
matter.
D
D
I
mean
I,
appreciate
that
it's
it's
something
which
is
very
applicable
to
the
folks
at
CN,
n--,
ik
and
and
and
in
china-
certainly
you're
you're
using
it
then,
and
it
works
for
you,
but
whether
there's
a
use
case
outside
of
that
context,
does
worry
me
a
little
bit
as
chair
and
trying
to
judge
consensus
and
yeah,
so
we're
running
really
short
of
time
with
two
other
presentations,
but
go
ahead
and
your
IRIScan
say
you're
up
at
the
mic.
You
might
as
well,
and
then
antoine
gets
last
word
here.
Well,.
T
I'm
andrew
sullivan
and
like
andy,
I
guess
I
don't
care
a
whole
lot
about,
although
this
process
thing,
except
that
I
recall
that
part
of
the
reason
a
lot
of
this
stuff
got
going
was
because
people
kept
saying:
there's
not
a
single
place
where
all
these
extensions
are
written
down
and
it's
causing
us
problems.
So
if
this
working
group
isn't
going
to
do
the
work
to
produce,
you
know
one
canonical
set
of
the
stuff
that
people
think
if
you're
gonna
do
one
of
these
things.
Here's
how
to
do
it
then.
T
Please
point
us
to
the
place
that
can
be
done
so
that
there's
this
consistency,
because
the
whole
point
of
people
that
it
was
supposed
to
be
extensible
like
not
in
a
million
trillion
pieces
right,
so
that
that
I
I
think
actually
there's
there's
a
positive
reason
to
prefer
publishing
the
document.
If
you've
got
interested
in
implementers
thanks,
yeah.
D
B
You
want
to
say
something
thing
on
what
you
responded
in
only
one
or
two
sentence.
What
am
I
feeling
about
the
these
things
make
me
a
little
confused
because
I'm
not
sure
whether,
when
we
make
conclusion
about
which
kind
of
draft
are
adopted
by
our
working
group,
it
we
repeatedly
discuss
each
time
about
this.
Draft
should
be,
do
should
be
adopted
by
working
group
or
not
Arredondo.
We
use
some
energy
to
discuss
that.
Every
time
we
can
we
may
have
newcomers,
and
newcomers
may
be
judging
us.
B
This
draft
we
do
not
use
and
do
not
need
use
our
our
working
group
energy
to
make
it
know
every
time
we
do
really
need
to
discuss
it,
I'm,
not
sure,
and
because
we
do
the
E's
used
our
energy
for
years,
make
reseller
draft
and
based
on
the
working
group,
discussion,
output
or
conclusion
we
we
we
modify
the
reseller
draft
to
to
the
general
organization
draft
and
somebody
stand
up
and
tell
us
these
things
doesn't
make
sense.
I'm,
labor,
confused.
M
Say
you
know,
the
registrar
should
always
be
in
the
middle
of
the
data
stream
and
they
should
always
be
aware
of
any
information.
That's
going
to
be
used
for
registrations
so
there
the
register
says:
okay,
we're
willing
to
play
this
middle
row
where
it
comes
to
data
that
guy
has
to
go
to
the
registry
and
for
this
old
document,
where
the
registry
has
some
need
for
specific
information
or
perhaps
even
in
the
benefits
of
the
registrant.
To
have
this
information
in
the
registry.
M
The
Registrar
says:
well
we're
not
interested
in
this
sort
of
information
work,
because
perhaps
we
can
do
there
can
be
some
things
be
done
with
this
data
that
is
not
in
our
interest.
I
find
that
a
bit
contradiction
Airy
to
each
other,
and
it's
it's
a
nice
discussion.
I
think
that
this
document
has
progressed
to
a
way
of
being
a
generic
organizational
extension
that
it
can
be
used
for
many
more
things
than
the
reseller.
D
S
Alright,
so
I
think
this
came
up
at
the
last
IETF
Mario
brought
up.
He
came
to
the
mic
and
said
something
about
schemas
or
ways
of
formalizing.
The
JSON
in
our
DAP
and
I'd
actually
worked
on
a
draft
that
it
expired
six
months.
Previous
to
that
and
for
some
reason,
I
had
dropped
the
whole
idea,
but
since
he
brought
it
up,
I
thought
it
was
a
good
idea
and
I
was
encouraged
to
update
the
draft
next
slide.
S
Please
so
our
app
uses,
JSON
and
one
of
the
problems
is
that
the
draft
that
you
know
there's
several
our
drafts,
but
the
one
that
actually
describes
the
JSON
is
very
long
draft.
What
makes
it
extremely
long
is
the
fact
that
all
that
JSON
is
described
in
prose
and
one
of
the
problems
that
we
ran
into
when
we
were
doing
the
going
through
the
whole
RFC
process,
and
there
was
the
you
know
the
weirds
interrupt
our
mailing
list
and
there
we
had
all
those
sessions
in
the
trauma
room
where
people
were
trying
to
get
there.
S
There
are
def
implemented.
There
were
a
lot
of
misinterpretations
about
what
some
of
that
meant.
So
that
was,
it
was
kind
of
a
problem,
but
we
still
today
don't
have
any
form.
You
know
we
work
through
it,
but
we
don't
have
any
formalism
for
for
what
we
describe
there.
So
this
can
make
testing
things
and
even
you
know,
developing
the
sock,
the
software
a
little
difficult
next
slide,
please.
S
So
this
draft
is
an
attempt
to
take
what's
in
in
the
RFC
and
actually
create
a
formal
syntax
for
that
JSON
there.
So
it
uses
this
thing
called
JSON
content
rules,
which
is
something
I've
been
working
on
for
a
while,
along
with
Pete
Cordell
and
basically
JCR
is
a
what
you
would
call
it:
data
definition
language
or
schema
language
for
json,
it's
very
similar
to
XML
schema
or
actually
more,
it's
more
akin
to
actually
relax
in
G
for
XML.
S
It's
concise,
more
concise
than
pro
so
once
people
know
how
to
read
it,
it's
easier
for
them
to
read.
The
other
thing
about
this
is
that
for
a
lot
of
people
who
aren't
native
to
English
reading,
all
those
pros
can
sometimes
be
a
little.
It's
not
the
easiest
thing
in
the
world.
So
when
you
have
a
formal
syntax,
it
makes
it
easier
for
them
to
understand.
What's
going
on
next
slide,
please
so,
why
do
so?
I
will
I
will
admit.
I
have
looked
at
a
lot
of
the
uses
of
JSON
I've.
S
Looked
at
a
lot
of
the
RFC's
that
we've
published
in
the
IETF
and,
to
be
honest,
the
vast
majority
of
them
do
not
need
this
type
of
thing
in
in
most
cases,
the
way
we
use
JSON,
especially
in
the
IETF,
it's
very
simple
and
putting
some
sort
of
formal
data
definition
language
in
there
would
probably
make
it
worse,
not
better.
That
being
said,
our
DAP
is
not
in
that
case,
in
that
category
our
tap
has
very
complex,
very
extensive
use
of
JSON,
where
we
have
a
lot
of
nested
objects.
S
We
have
a
lot
of
objects,
get
reused
all
over
the
place.
So
it's
it
is
not
in
that
that
same
category
there's
actual
good
candidate
for
a
DDL.
This
is
a
quote.
Actually,
when
we
were
going,
we
were
went
to
the
RFC
process.
We
got
the
IETF
last
call
feedback,
and
this
is
what
Tim
Bray
said:
Tim
Bray
is
not
a
very
big
fan
of
DD
l's,
but
he
actually
said
you
know.
This
is
a
good
case.
This
is
a
good
candidate
for
it.
S
So
next
slide,
please
just
a
little
bit
about
JCR
here
JCR
is
is
actually
a
superset
of
json.
So
if
you're
going
to
read
json
you
it's
easy
to
kind
of
come
into
what
JCR
is,
and
we
have
we
actually
looked
at
and
we
put
features
in
there
to
try
to
help
people
who
are
implementing
software,
create
compatibility
kits
and
test
Suites.
S
So
in
the
first
box
up
here
we
have
actual
actual
JSON
snippet
from
RFC
7159,
and
the
second
box
is
actually
the
JCR,
which
is
basically
saying
you
know
the
first,
the
the
first
eye,
the
first
member.
There
is
a
string,
the
second
one's,
an
integer
that
starts
with
zero
to
infinity
and
so
forth,
and
then
we
continue
abstracting
it
by
the
time
you
get
down
to
the
the
green
box.
This
is
what
you
could
use
for
testing.
S
You
can
say,
for
this
particular
use
case,
make
sure
that
this
this
rule
has
a
specific
value,
and
this
other
rule
has
a
specific
value.
So
I
don't
go
into
the
full
these
details
of
what
JCR
is,
but
that's
that's
essentially
what
it's
about
next
slide,
please.
So
where
am
I
with
the
JCR
for
our
tap
graph
at
the
moment?
I'm
collecting
feedback
Mario
had
a
lot
of
comments
and
someone
else
had
a
lot
of
comments
on
the
mailing
list.
S
It
was
all
very
positive
and
basically
showing
me
that
I
hadn't
quite
read
the
our
tap
JSON
correctly
or
there
were
things
I
hadn't
put
into
the
JCR,
which
is
kind
of
interesting
since
I'm
the
author
of
the
art,
app
JSON
draft
RFC.
So
there
again
it's
very
complex
and
so
there's
a
lot
of
stuff.
You
can
miss
in
there
there's
an
art
app
plan.
I
have
called
Nick
info,
it's
a
command
line,
client
and
what
I
want
to
do
next
is
I
want
to
take
the
JCR
that
we
have
and
apply
it
to
that.
S
The
other
thing
is
next
year
at
Aaron
we
are
looking
at
expanding
our
internet
routing
registry,
and
one
of
the
things
we
want
to
do
is
throw
routing
route
objects
into
our
tap
as
well,
and
so
we're
gonna
be
writing
a
bunch
of
extensions
and
to
do
that,
as
opposed
to
doing
more
lengthy
drafts
that
have
a
bunch
of
pros
in
there
we're
actually
in
a
look
at
using
JCR.
For
this,
we
already
use
it
for
doing
inter-rir
transfers
between
all
the
rars.
S
G
Am
Mario
Fredo
from
registered
OTT
and
I'm?
You
know
they
are
in
for
I'm
following
another
approach
based
on
the
json
schema.
Honestly,
I'm
I
say
I
must
say
that
just
some
country
rules
are
better
than
the
jesus
schema
because
are
more
compact,
compact
and
because
there
are,
they
are
more
compliant
to
more
naturally
complain
to
to
the
way
to
the
style.
G
One
issues
is
about
the
deluxe
of
a
description
of
the
requests
and
the
relationship
between
requests
and
responses
that,
as
far
as
I
know,
it
is
working
in
currently
in
UCR
and-
and
the
second
issue
is
about
the
the
number
of
implementation
supporting
Jesse
are
currently
I.
Think
there
are
very
few
implementations
about
Jesse.
Are
we
respect
to
the
implementation?
G
The
number
implementation
about
the
Jesus
schema,
so
I'm,
not
a
fan
of
Jesus
keema,
but
when
I
try
to
find
a
a
data
definition,
language
of
JSON
based
rest
services,
I
found
a
lot
of
materials
about
Jesus,
keema
and
libraries.
Examples,
tutorials
and
quite
nothing
about
Jessie
are
so
III
I
was
oriented
to
to
use
it.
You
so
schema
to
describe
the
adapt
responses
and
records
yeah.
S
So
let
me
address
that
the
first
part
about
the
things
that
Jason
schema
does
with
meta,
schemas
and
so
forth.
That
was
never
a
goal
of
JCR
the
way
you
know
art
app
says
this
query
gets
this
object,
is
an
RFC,
not
not
some
other
means
so
yeah.
There's
a
lot
of
things
at
jason.
Schema
attempts
to
solve
that
JCR
is
just
was
never
designed
for
was
never
was
never
what
they
intended
to
do.
S
Jason
schema
is
a
much
larger
community,
I
will
admit
much
larger
and
because
it's
in
JSON
there
there
are
implementations
are
a
little
easier
to
do,
but
there
are
also
a
lot
of
problems
with
it.
They
continue
to
iterate
as
well
and
I'm,
not
saying
that
one's
better
than
the
other,
the
it's
just
that
you
know
I
in.
S
In
my
opinion,
I've
read:
JSON
schema
I've
attempted
to
use
it
I,
always
I
always
find
something
I
don't
like
about
it,
and
that's
why
we
went
down
this
whole
JCR
route
to
begin
with,
when
it
comes
to
what
we
want
to
do,
what
we
want
to
say
in
the
IETF
about
whether
this
is
done
in
JCR
or
json
schema
or
whatnot.
I
don't
know
what
the
correct
answer
to.
That
is
the
one
of
the
things,
and
I
don't
know
if,
if
there
is
a
correct
answer,
I
think
that's
a
better
way
of
putting
it.
S
E
Scott
Hollenbeck
so
generally
I
like
this
approach,
which
is
one
of
the
reasons
that
when
we
did
EPP
I
used
XML
schema
because
it
gives
you
a
nice
automated
way
of
validating
certain
things.
But
I
didn't
have
a
question.
So
the
RDF
JC
document
depends
on
your
generic
JCR
document,
correct
mm-hmm.
All
right.
Are
you
suggesting
that
the
working
group
eventually
adopt
both
because
we
can't
do
the
are
DAP
one
without
the
JCR
one
existing?
That's
a
good
question
and
I.
E
D
Would
you
say,
I
didn't
well,
I
would
probably
send
it
off
to
the
dispatch
group
and
let
them
sort
it
out
honestly,
but.
S
S
U
D
C
S
I
really
don't
like
that
answer,
because
that's
a
not
JSON
and
they
had
different.
They
have
different
things
they're
doing
in
there.
The
the
other
thing
is
is
that
it,
the
you
know
the
one
of
the
the
the
when
they
started
that
work.
They
actually
cited
the
JCR
draft
as
where
they
got
some
of
their
ideas
from
we've
iterated
on
this,
since
they
did
their
their
initial
their
initial
work-
and
this
is
much
the
things
we've
done
in
JC-
are
much
more
specific
to
JSON
than
what
you
can
do
with
CD.
S
Know
it's
one
of
those
projects
that
that
I
work
on
you
know
from
time
to
time.
I
haven't
had
to
do
it,
full-time
the
no
to
be
honest.
I
haven't
talked
in
the
JSON
working
group
about
this
for
a
while
I,
remember,
yeah,
it's
been
a
while
the
the
and
and
we
have
gotten
feedback
from
there,
and
that
a
lot
of
that
feedback
has
been
incorporated
into
the
current
draft,
whether
what
the
IETF
does
with
that
I
don't
know
like
I
said:
I,
don't
have
the
answer
to
that
I.
Don't
think
cuddle
is
a
good.
S
Is
me
rephrase
that
I
don't
think
cuddle
is
necessarily
the
right
solution
for
people
who
are
doing
complex
JSON
because
first
off
its
not
JSON
itself,
it's
talking
about
C
bore
the
and
the
other
thing
I
want
to
be
very
careful
about
is
I,
don't
really
I
know
the
JSON
schema.
People
also
have
internet
drafts
and
I
I'm
on
their
mailing
list,
but
I,
and
they
talk
about
revising
it
and
I.
Don't
know
when
they're
gonna
do
that
I
don't
want
to
get
into
this
little
fight
with
them
either
so
I'm
kind
of.
C
C
W
You
know
Tim
results.
Ripens,
you
see,
I
just
want.
I
wanna
keep
this
very
short,
I'm
not
aware
of
all
the
other
efforts
in
this
area,
but
what
I
really
like
about
this
is
that
it's
you
know
easy
to
understand
and,
and
it's
not
trying
to
solve
everything
in
the
world
to
me-
that's
really
useful.
If
you
just
want
to
have
a
quick
clarification
of
you
know
whatever
you're
specifying
so
I
think
this
is
useful.
Were.
V
S
V
Okay
and
I'm
sympathetic
to
that,
it's
one
to
make
sure
I
mean
if
that
were
the
rose.
I
was
going
to
point
out
some
reasons
that
shouldn't
happen,
but
if
that's
not
what
you're,
proposing
I'm
good
with
y'all
playing
around
with
this
sort
of
individual
I
think
we
probably
want
to
have
a
story
for
how
we
would
get
whatever
your
underlying
technology
is
pushed
through
to
an
RFC.
Before
you
start
putting
working
group
drafts
on
top
of
it,
yeah.
S
C
G
Hello,
everybody
I'm
Mario
Fredo
from
registered
OTT,
and
this
presentation
I
talk
about
three
adapt
draft
and
namely
shorten
paging
partial
response
and
reverse
research.
This
next,
the
three
drafts
are
quite
recent.
The
first
draft
is
at
its
second
version,
and
the
first
version
was
submitted
on
last
May.
Next,
please.
G
The
first
two
draft
shares
the
same
goal:
to
bring
best
operation
practices
in
rest
services
design
in
into
a
DAPA.
We
all
know
that
rest
services
should
offer
capabilities
for
result,
filtering
sorting,
paging
and
sub
setting
for
many
reasons,
minimize
the
traffic
on
the
net
speed
up
response
time,
improve
the
precision
of
the
query
and
obtain
more
reliable
results,
decrease
the
load
of
the
serve
and
equity
processing
and
spend
less
CPU
time
on
a
memory
on
the
client.
G
In
fact,
you
cannot
restrict
result
set
by
adding
for
the
search
condition
you
can
obtain
in
the
response
the
total
number
or
Jets
found,
and
you
cannot
specify
possible
sorta
criteria
to
have
the
most
relevant
object
at
the
beginning
on
the
result
set
that
to
avoid
the
truncation
or
relevant
results.
Besides,
you
cannot
scroll.
This
upset
when
the
result
set
is
truncated
and,
finally,
service
can
only
provide
full
responses.
Next,
please,
to
overcome
these
inefficiencies,
the
sorting,
a
paging,
a
draft
presents
four
new
parameters,
counter
a
boolean
value
that
allows
to
obtain
and
response.
G
The
total
number
objects
found
that
do
due
to
the
truncation
can
be
different
from
the
number
of
returned.
Objets
sort
by.
That
is
a
string
value
that
allows
to
specify
sort
order
for
result
set
and
the
limit
and
offset
the
that
allows
to
specify
what
portion
of
the
entire
data
set
must
be
returned
limit
and
offset
together,
implement
implement
result
set.
Pagination
new
properties
in
the
response
are
consequently
added.
G
Fetching
count
is
reporting
the
response
when
the
count
parameter
is
put
in
the
query
string
and
this
set
to
true
value
and
paging
links
that
provide
the
ready-made
reference
to
the
next
page
of
the
result
set
when
the
truncation
takes
place
service
returning,
paging
links
and
paging
count.
Properties
must
include
the
appropriate
string
in
the
arab
conformance
array,
and
this
has
been
proposed.
G
G
Next,
please,
these
in
the
desolated,
I
reported
the
two
samples
of
the
response,
including
paging
countin
pudgy
links
based
on
offset
in
the
first
example
they
and
the
result
set
is
truncated
and
the
pudgy
links
reports,
links
linked
to
the
next
page
of
the
results
set,
and
the
second
example
is
diversion
or
the
patient
links,
property
that
uses
the
cards
or
option
next
please.
But
what
are
the
pros
and
the
cons
of
offset
and
the
cards
or
based
pagination
offset
pagination
is
supported.
G
Natively
natively
by
major
relational
DBMS
is
a
most
popular
and
no
secret
that
databases,
so
it's
very
easy
to
implement.
It
provides
mass
maximum
flexibility,
but
does
not
scale
well
in
case
of
huge
result.
Sets
I
think
that
here
the
the
the
limits
of
over
which
to
consider
result
assert
a
huge
is
one
hundred
thousand
records.
It
may
return
in
unconscious
and
pages
when
data
are
very
frequently
updated,
but
I
think
that
this
is
not
the
case
of
registration.
G
G
It
needs
that
all
comparison,
it
sort
operation
had
to
be
reverted
if
a
server
want
to
implement
also
backward
pagination.
It
arises
the
further
issues
when
objects,
aggregate
information
coming
from
different
possible
different
data
sources
like
entities
that
maps
information
belonging
to
different
entity
rules,
it's
not
flexible
because
it
does
not
allow
to
sort
by
Anik
any
field
and
paginate
the
results,
because
the
sorting
has
to
be
made
on
the
key
field.
It
does
not
allow
to
skip
pages
because
pages
I
up
to
be
scroll
at
the
sequentially
starting
from
the
initial
page.
G
G
G
G
We
can
distinguish
two
approaches
to
the
implementation
of
partial,
a
partial
response,
the
first
approach
that
we
can
call
the
fields
approach
is
used
by
leading
REST
API
providers
and,
according
to
it,
the
client
declare
explicitly
the
data
fields
to
obtaining
the
response.
The
second
approach
that
we
can
call
fields
is
used
in
digital
libraries
and
bibliographic
catalogs,
and
according
to
declare,
the
client
declares
a
name
identifying
a
several
predefined
set
of
data
fields.
G
What
are
the
characteristics
of
the
two
approaches
of
fields
provides
maximum
flexibility,
because
clients
can
specify
exactly
the
fields
they
need.
It's
not
easy
to
implement
because
the
fields
have
to
be
declared
according
to
a
given
syntax
and
the
presence
of
arrays
and
de
ponerse.
The
objects
may
complicate
both
for
syntax
definition.
Consequently,
the
server
processing
of
the
query:
it
does
not
facilitate
interoperability,
because
clients
should
perfectly
know
the
stretch
of
the
return
and
object
to
avoid
the
declaration
on
him
invalid,
the
list
of
fields.
G
The
latter
approach
is
legs,
flex
roller,
but
do
added
up
a
user
really
need
the
maximum
flexibility.
Probably,
no
because
I
think
that
other
users
quite
always
request
that
the
same
set
of
strongly
related
data
fields,
it
can
be
easily
implemented
and
it
facilitates
interoperability
because
the
server
can
define
some
basic
field
sets
with
which,
if
known
previously
by
the
client,
can
increase
the
probability
to
get
valid
the
responses.
G
G
The
list
of
fees
for
each
set
can
be
different
according
to
the
access
levels
and
some
field
sets
could
be
able
to
be
available
only
to
some
users.
Next,
please
so.
The
posture
response
draft
introduces
one
new
parameter
field
set,
that
is
a
string
value
in
define
a
predefined
set
of
fields
to
facilitate
interval.
Interoperability.
G
We
think
that
some
values
are
required,
the
ID
that
contains
only
the
object,
class-name
field
and
the
field
identifying
the
object
it
can
be
used
when
the
kind
wants
to
obtain
only
a
collection
of
object.
Identifiers,
brief:
it
contains
the
fields
that
can
be
included
in
a
short
response.
It
can
be
used
when
the
client
is
requesting
for
a
set
of
properties,
which
gives
only
a
basic
knowledge
of
each
object
and
the
full
that
contains
all
the
information
the
server
can
provide
for
a
foreign
object.
Additional
conduct.
Consideration
can
be
made.
G
C
G
Last,
the
last
draft
is
about
rebus
search.
You
know
all
that
robot
services
provided
my
many
web
application
and
the
users
through
these
service
users
can
find
domain
names,
starting
from
the
owner
details,
but
currently
registered
already
performer
alert
searches
because
they
provide
the
register
with
domain
names
related
to
contact
main
server
and
the
NSS.
The
NSS
Aki's
reason
possible.
Reason
to
these
requests
are
the
loss
of
synchronization
between
registrar
data
registry
data
and
the
need
of
such
data
to
perform,
but
a
PP
updates.
Next,
please.
G
In
the
past
has
been,
there
has
been
some
possible
objection
to
the
implementation
or
reverse
reasonable
search
engine
general.
One
is
potentially
privacy
risks,
but
I
can
itself
points
out
that
reverse,
which
is
allowed
when
it
is
driven
by
some
permissible
purposes.
It
provides
adequate
security
policies
and
the
other
and
aldub
provide
these
security
policies
because
it
relies
on
features
available
in
other
layers.
G
The
second
concern
has
been
about
impact
on
server
processing,
but
are
the
kerreri
support,
searches
and
the
impact
above
standard
that
the
researchers
came
can
be,
is
absolutely
similar
and
can
be
mitigated
by
several
opting
a
doc
policies.
Next,
so
am
the
draft
proposes
new
segments,
part
two
of
the
endpoint
domains.
Entity
handle
entity
F
and
the
search
parties
are
the
same
as
specified
in
RFC.
G
74,
82
and
new
parameters
is
also
proposed
and
tadaryl
that
allowed
to
restrict
results
to
a
specific
entity.
Role
since
in
are
the
penta
T's
are
in
relationship
with
all
searchable
objects.
It
is
possible
to
evaluate
this
tension
to
other
parts.
Next
skip
skip.
No.
No.
The
last
slide,
I
think
that,
at
some
point
of
discussion
in
within
the
working
group
with
regards
to
the
sorting
and
paging
I'll
shoot,
the
sorting
properties
be
define.
Is
a
national
registry
appropriate
all
might
new
parameters
work
without
use
of
a
relational
DBMS?
G
Should
our
top
specification
aboard
both
offset
and
culture
parameters
and
elect
operators
to
implement
pagination
cordeen
to
their
needs
to
the
user,
access
levels,
resubmit,
queries
and
Weber
gas
to
reverse
a
search?
Should
reverse
cells
should
be
based
on
other
anti
details?
Should
reverse
er
should
be
based
based
ended
to
the
other
types
of
searches?
D
For
working
with
adoption,
or
anything
like
that,
you're
just
bringing
this
to
the
attention
to
the
working
group-
yes,
okay,
all
right
so
I
mean
I
just
wanted
to
add.
Then,
from
from
my
own
point
of
view,
you
know
speaking
as
chair.
I
think
this
is
is
interesting
and
important.
Stuff
I
do
think
this
working
group
is
at
least
the
mailing
list
is
an
appropriate
place
to
discuss
this.
That's
why
we,
you
know,
wanted
to
go
along
with
this
presentation
being
here
and
getting
some
discussion,
but
you
know
what
we
do
with
it.
D
S
Andy
Newton,
so
my
first
comment
is
and
I'm
sorry
I
haven't
had
a
chance
to
read
all
I
read
some
of
it
and
I
didn't
I
didn't
realize
how
many
drafts
you
had,
but
it
all
looks
very
interesting,
I
think
before
we
would
do
anything
like
this
on
either
three
of
the
drafts.
We'd
want
the
OAuth
open,
ID
connect
stuff
in
first,
because
a
lot
of
this
stuff
is
stuff
that
in
general,
the
probably
the
general
public
wouldn't
be
wouldn't
be
doing.
S
Secondly,
you
wanna
get.
This
conversation
is
working
about.
What's
supposed
to
be
information
on,
what's
supposed
to
be
standard
or
whatnot,
this
is
all
very
foundational
work.
So
I
do
think
this
is
the
right
place
with
the
working
group,
and
it
should
be
done
here
if
Mario
wants
to
take
it
forward.
It's
gonna
be
a
lot
of
work,
but
I
do
think
this
would
be
standard
track.
Work.
E
Scott
Hollenbeck
and
there's
a
corollary
to
what
Andrew
mentioned
earlier
in
the
context
of
EPP
right
now,
we're
not
well-suited
to
take
on
new
work.
I
know
I've
been
trying
to
get
a
particular
draft
adopted
or
go
at
least
have
the
question
posed
to
the
group
now
for
quite
some
time
and
I'm
continually
told
that
we
need
to
clear
our
plate
a
little
bit
all
right.
E
We're
going
to
get
bypassed,
I
mean
I.
Thought
myself
about
just
saying
you
know
forget
this
working
group
and
I'm
gonna
go
have
a
little
chat
with
the
ad
about
doing
an
ad
sponsored
draft,
because
I've
got
operational
problems
to
solve
alright.
So
please,
let's
get
our
place
cleared.
Let's
think
about
some
of
these,
our
DAP
focus
documents
and
let's
get
some
answers
out
there.
E
D
And
speaking,
is
chair
and
and
not
and
and
I
have
not
obviously
coordinated
us
with
Antoine
I
mean
to
me
one
of
the
important
questions
about
what
this
group
does
or
doesn't
take
on
is
the
amount
of
work
that's
involved.
I
mean
this
is
looking
like
it
could
be.
You
know
substantial
that
have
worked
and
I
suspect
that
it
probably
is
more
appropriate.
It
may
or
may
not
be
an
appropriate
document
for
this
group
to
take
on
you
know.
D
We
really
had
created
this
working
group
to
deal
with
extensions
EPP
and
our
DAP
extensions,
and
this
feels
like
it
might
be
a
little
more
than
that.
So
it's
a
question
worth
considering
and
I'm
sure
when
the
time
comes,
our
ad
will
have
an
opinion
about
that
too.
So
it
might
end
up
being
something
that
spun
off
and
can
be
dealt
with
separately.
Just
for
that
reason,
so,
okay,
I,
you
said
you.
G
Now
I
should
say
that
I
think
that
that
there
are
some
other
implementers
that
are
asking
me
about
these
drafts,
especially
sorting
and
paging
draft
brahma
mahad
is
it's
only
an
example
of
people
that
are
implementing
the
adapt
servers.
So
I
think
that
this
topic
should
be
a
should
be
defining
the.
If,
if
we
can
think
that
that
they
are
interesting,
but
it's
only
my
opinion
is
not
I
think
that
this
idea
should
be
shared
by
the
entire
working
group.
E
Eventually,
I
do
intend
to
request
that
the
working
group
consider
adopting
that
document,
but
there's
one
thing
in
particular:
that's
holding
me
back
on
that
right
now
and
that's
that
the
document
talks
about
this
notion
of
acceptable,
acceptable,
query
purposes
right
and
at
least
in
the
gTLD
space
that
is
very
policy
dependent
and
the
policy
work.
That's
touching
on
this
question
of
query
purpose
is
still
very
much
a
work
in
progress,
so
it
may.
This
may
be
a
question.
G
I
honestly
I
put
the
the
the
the
point
of
Ravel
to
ease
and
permissible
purposes
of
queries,
because
I
found
I
found
the
the
dystopic
tree
treated
in
the
icon
document.
But
my
my
idea
when
I
I
I
I
wrote
the
the
the
draft
and
implemented
these
on
dot
IT
public
test
server
was
to
give
an
answer
to
the
dot
ID
registrar's,
asking
for
the
list
of
domains
related
to
contacts
unrelated
to
taking
your
contacts
or
related
to
resistance,
because
so
a
III
have
a
photo
to
this
solution.
J
Roger
yeah
this
Roger
I've
got
a
little
optimistic
on
the
five
months
and
maybe
London
but
I
had
purpose
is
definitely
being
talked
about,
so
hopefully
we
do
get
to
that
spot
and
then
your
future.
It
was
interesting
that
I
actually
came
up
here
to
say
something
and
in
your
last
comment
just
made
me
think
about
that,
but
a
from
a
registrar
standpoint,
I,
don't
really
see.
I
mean
see
this
as
being
useful
for
a
registrar,
I.
J
Think
it's
interesting,
but
I
mean
we
would
definitely
not
implement
this
on
our
our
DAP
implementation.
But
your
point
about
registrar's
asking
you
for
a
list
like
this
I.
Don't
know:
I
I,
just
don't
see
registrar's
being
all
that
interested
in
this,
but
I
didn't
see
it
from
a
registries
perspective
of
a
registrar
asking
now
I,
don't
think
we
would.
But
that's
that's
a
different
point
at.
G
X
X
G
S
D
Okay,
so
we
were
for
those
remotely
we
just
sort
of
cut
off
by
some
discussion
in
the
room
about
we
don't
want,
listen,
EPP.
So
that's
why
this
is
in
our
tap
of
appropriate
thing.
So,
okay,
okay,
you
don't
all
right.
So
that
brings
us
to
a
discussion
about
interim
eating
feedback.
Oh
Oh
Cody
was
in
the
queue
and
he
took
himself
out
of
the
queue
okay,
so
I
got
that
the
interim
eating
was
yours
Roger.
J
Roderick
and
so
I
think
we've
had
three
now
for
the
first
two
were
very
productive:
I
think
that
it
was
maybe
the
content
that
was
appropriate
for
everyone.
I,
don't
know
that
interested
the
last
one.
We
got
zero
participation,
there
was
four
or
five
was
on
the
call,
but
it
was
those
that
arranged
the
call.
So
we
did
it.
We
did
discuss
things
and
we
made
decisions
for
everybody,
so
I'm
glad
everybody
attended
now
I
think
a
interim
meeting
has
worked
out
well
on
the
prior.
J
This
last
one
again
was
not
attended
well,
but
I
think
it
was
more
content.
The
fee
document
has
been
worked
quite
well,
so
I
I
think
people
are
starting
to
lose
the
interest
on
discussing
those
last
little
details
to
get
through.
So
but
again,
the
the
last
meeting
was
not
what
was
anticipated,
but
again
it's
it's,
not
I,
guess
unrealistic
for
people
not
to
show
up
when
it
starts
to
tail
off.
So
so
my
only
comment,
I,
don't
know.
If
anybody
had
questions
about
the
meetings
here
in.
D
General
I
just
want
to
say,
I,
think
the
working
group
I
think
the
interim
meetings
are
working.
It
certainly
has
helped
to
move
along
the
couple
of
documents
that
Roger
is
impressing.
You
know
to
to
get
done
and
in
a
good
state
as
as
to
where
we
are
and
in
theory
the
working
group
session
that
we
would
have
had,
but
doesn't
look
like
we're
going
to
have
at
the
moment
here
would
have
done
the
same
thing
to
help
move
along
some
new
ideas
so
and
end
the
validate
document.
D
D
S
We
I
was
wondering
if
we
want
to
start
thinking
about
some
BCPs
for
our
tap
to
things.
Just
recently
happened
that
I
think
would
be
interesting
as
more
people
start
spinning
apart
app
servers,
one
was
someone
started,
circulating
a
list
of
conformance
issues
with
our
tap
and
they
were
content.
They
were,
like
you
know,
hey
Scott,
you
know
the
person
who
runs
the
server
and
you
know
Ford
this
email
on
and
so
that
basically
chain
emails
that
were
going
on
trying
to
get
to
the
the
people
who
were
authoritative
for
the
servers.
S
So
we
might
want
to
consider
like
a
BCP
on
putting
something
in
the
/
help
of
how
do
you
contact
the
people
to
actually
operate
the
server?
The
other
one
is
we
might
want
to
have
to
visit
the
whole
thing
about
putting
HTTP
and
HTTPS
URLs
in
the
Ayana
bootstrap
files
I
run
into
some
problems
with
my
client
people
reporting.
S
They
can't
talk
to
certain
registries
because
of
TLS
issues
so
like
a
lot
of
Mac's,
apparently
ship,
an
extremely
old
version
of
open
SSL
that
doesn't
talk,
newer,
TLS,
and
so
they
can't
end
up
talking
to
these.
Our
tap
servers
because
they
only
list
the
HTTPS
URL,
which
is
what
we
want
them
to
do
if
they
can
do
it,
but
some
people
might
want
to
drop
back
to
doing
an
insecure,
just
regular,
HTTP
thing.
So
that's
also
something
might
want
to
think
about.
D
C
D
Q
Stefan-Boltzmann
ethnic,
as
seen
on
TV,
no
as
seen
on
the
mailing
list
as
I've
been
a
discussion
in
DNS
up
about
the
possible
registration
of
a
dot
Indianola
local
TLD
on
one
of
the
point
was
a
it
was
planned
to
edit
in
the
wood
onto
delegated,
to
a
s11
to
with
the
name
on
FC
75.
35
explains
why
it
has
to
be
de
name
on
not
NS
record
on.
Q
One
of
the
things
that
were
mentioned
was
that
currently
I
am
now
on
the
Verisign
communicates
about
EPP
for
the
management
of
the
root
zone,
and
there
is
no
way
a
PP
to
delegate
a
name
with
denimm.
We
called
only
with
NS
records.
So
the
point
was:
is
it
a
good
idea
to
create
a
new
mapping
or
to
extend
the
RC
57:31
mapping
for
domain
name?
Is
it
a
good
idea,
stupid
idea
it
does
it
have
to
be
a
RFC
or
trust
a
local
extension,
so
commensal
IDs.
Our
welcome.
D
E
A
D
D
I
do
think
that
our
our
mailing
list
is
available
for
broad
and
open
discussion
about
issues
there
really
isn't
any
other
home
for
any
kind
of
registration,
related
question
or
or
discussion,
and
we
just
have
to
see
if
there's
traction
for
doing
the
work
and
then
we
get
to
examine
whether
or
not
it
needs
to
be.
You
know.
D
However,
this
working
group,
its
Charter,
is
really
is
restricted
to
just
EPP
extensions
and
our
dap
extensions
it.
It
really
is
not
within
its
charter
to
do
slightly
more
broad-based
documents
related
to
registration
in
general.
However,
as
part
of
the
discussion
that
we
had
a
year
ago
about
adopting
these
documents,
when
we
had
that
whole
concept
set
aside
until
we
cleared
our
docket
and
our
docket
is
clearing
and
we're
becoming
eligible
to
add
new
documents
onto
our
list,
we
have
also
again
started
the
discussion
with
our
Area
Director
about
broadening
our
Charter.
D
So
we
can
take
on
some
of
these
other
topics
and
adopt
these
documents,
and
you
know
our
area
director
will
be
paying
attention
to
that
and
will
work
with
us
to
to
get
the
right
words
that
we
can
use
and
then
we'll
get
our
charter
run
through
the
approved
process
that
it
needs.
And
then,
as
these
documents
clear,
we
can
quickly
adopt
the
other
documents,
but
we
should
be
in
a
pretty
good
place
here.
D
I
think
that
you
know
before
the
London
meaning
we
should
have
cleared
off
a
number
of
documents
and
adopted
a
bunch
of
new
documents
and
have
new
ongoing
work.
That's
happening,
I
mean
that's
my
goal
here,
just
speaking,
without
actually
coordinating
specifically
with
Antwan
about
it,
but
in
general
that
that's
a
goal
about
moving
stuff
forward.
Okay,
one
less
so
that
was
my
comment
there.
Let
me
just
pause
and
see
if
anyone
has
any
questions
or
comments
about
that
before
I
move
on
to
one
last
thing
and
not
seeing
anybody
jumping
up.
D
Okay,
so
Roger
you
one
who
had
the
two
documents
that
you
wanted
to
have
a
working
session
about.
We
have
totally
usurped
that
time.
I
do
apologize
for
that,
but,
on
the
other
hand,
I
think
we
were
having
some
really
good
discussion
here
and
I
really
didn't
want
to
want
to
set
that
aside.
It
I
think
this
is
a
good
time
to
bring
up
the
fact
that
the
IETF
does
at
this
meeting.
They've
had
it
before
it's
been
an
experiment
and
it's
been
working
out.
D
D
So
if
you
have
an
account
on
the
on
the
wiki,
there's
a
way
to
go
up
and
sign
up
and
and
and
sign
out
the
room
for
an
hour,
and
actually
you
can
they
actually
encourage
multiple
people
to
sign
out
the
room,
especially
in
the
case
of
the
larger
one,
because
that
way,
you
get
you
know
cross
communication,
but
you
can
find
a
corner
of
the
room
to
sit
down
and
work.
So
what
I
wanted
to
offer
to
you
is
if
it
rather
than
saying
that
we
have
totally
given
up
on
those
working
sessions.
D
If
you
want
to
look
and
see
about
signing
out
a
room
slot,
maybe
we
can
have
a
little
bit
of
a
dialogue
on
the
mailing
list
about
finding
a
good
time
to
sign
it
out,
for
you
can
go.
Look
at
some
options,
pick
something
that
works
for
you
and
and
then
you
know,
try
and
work
something
out
on
the
mailing
list
and
see
if
we
can
pick
a
couple
of
those
dot,
those
two
documents
and
pick
up
some
work
sessions
for
them.
Otherwise,
we'll
continue
with
our
interim
model
and
I'll.
J
Thanks
to
miss
Roger
I
think
that's
good
to
know.
I
didn't
realize
that,
but
it
may
be
difficult
to
find
time,
but
we
can.
We
can
try
that
definitely
I'm
going
to
try
to
promote
the
the
next
interim
meeting
then
so
that
we
can
get
on
to
these
topics
and
and
the
the
registry
mapping
topic
will
be
a
big
one
and
a
long
one.
J
U
Alex
me
over
one
thing
that
came
up
in
our
ongoing.
Our
deaf
implementation
efforts
is
that
the
exact
semantics
of
the
search
with
the
asterisk
are
a
little
bit
unspecified
any
RCS,
so
I'm
getting
a
lot
of
heat
from
our
developers
for
not
working
with
you
guys
correctly
and
getting
the
right
language
into
the
RFC's.
U
D
Okay,
let
me
just
suggest
that
wants
to
talk
about
searching,
should
please
come
on
up
here
in
the
beginning
and
and
talk
to
Alex
and
see
if
we
can
set
that
time
up.
In
fact,
actually
those
who
want
to
continue
with
the
working
session
might
actually
come
up
here
at
the
end
of
the
meeting
and
and
touch
base
with
Roger
right
away,
because
maybe
if
you
don't
actually
get
a
good
group
of
traction,
you
want
to
make
time
you
might
as
well
just
go
for
an
interim
meeting.
D
It
did
not
work
that
hard,
but
let's
see
if
we
can
get
to
or
through
people
up
here
get
some
some
traction
to
have
that
meeting
and
then
one
last
thing
before
Scott
talks.
If
anybody
has
not
signed
the
blue
sheet-
and
you
want
it,
please
be
sure
to
come
on
up
here
after
this
meeting
is,
is
about
to
be
over
and
and
sign.
E
Yeah
Alex
I
think
you
owe
your
observation
about
that
text.
Correctly.
Captures
the
confusion
of
the
author
in
in
trying
to
capture
the
working
groups,
consensus
on
how
that
all
worked
which,
as
in
it's
a
complete
mess,
but
having
said
that
I
do
have
another
internet
draft
out
there
that
talks
about
doing,
searching
using
POSIX,
regular
expressions,
which
I
think
is
very
well
specified
and
if
that
would
potentially
be
a
solution.
Let's
have
a
conversation
about
that
as
Jim
Jessa.
D
No
okay.
Well,
then,
I
want
to
thank
everyone.
This
really
has
been.
You
know
an
exceptionally
good
working
group
meeting
for
this
working
group
over
the
past
year.
I'm
really
excited,
and
we
had
some
really
good
discussion
and
and
I
appreciate
that
I
really
do
so
thanks
very
much
for
that
look
forward
to
seeing
more
activity
on
the
mailing
list.
Please,
if
you
want
a
working
session
with
Roger,
come
on
up
and
and
make
that
known
and
other
than
that
were
adjourned.