►
From YouTube: IETF99-REGEXT-20170718-1330
Description
REGEXT meeting session at IETF99
2017/07/18 1330
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
Oh
is
that
the
problem
didn't
even
occur
to
me
to
switch
on
the
microphone.
I.
I
guess
I
didn't
need,
I
didn't
realize
it
wasn't
sounding
in
the
room,
so
it
sounds
better
now
even
out
in
the
room.
Oh
alright.
So
now
I
assuming
need
echo,
can
hear
me
now
and
he
couldn't
hear
me
before
antoine.
You
want
to
step
into
the
room
and
say
hi
and
just
confirm
for
us
that
the
meet
echo
is
working.
C
D
B
B
Okay,
the
usual
note.
Well,
so
if
anybody
has
any
questions
or
whatever
about
this,
encourage
you
to
talk
to
your
own
lawyer
and
then
come
back
and
tell
us
what
you
decided,
but
in
any
case
the
ITF
owns
you
that's
the
only
thing
you
need
to
know.
That's
the
pit!
That's
right!
You
know
the
right
to
remain
silent,
that's
what's
important
and
not
fill
out
the
blue
sheets,
oh
and
speaking
of
blue
sheets.
A
B
That
was
my
one
flaw
in
this
process:
what's
not
getting
it
Lou
sheets
ready
I'll
do
that
in
a
in
a
moment.
This
is
just
a
standard
slide
that
we
put
up
here
about
document
reviews
I
mean
we
have
the
same
problem.
Other
groups
have
this
problem.
You
know
I
mean
that
I
think
that
you're
sensitive
more
sensitive
to
it.
When
you're
a
document
author,
you
know,
but
you
know.
Obviously,
if
you
want
people
to
review
your
document,
you
should
be
willing
to
review
theirs
and
I.
B
Think
it's
a
good
exercise
for
people
anyway
to
review
documents.
I
mean
it's
important
to
the
to
the
progress
of
the
standards
and-
and
we
certainly
appreciate
that,
okay
moving
on
to
welcome
in
introductions,
so
we
have
a
jabber
scribe
and
note
scribe
and
already
introduced
myself
an
Antoine.
So
that's
good!
So,
let's
jump
to
talking
about
our
existing
document
status
very
quickly.
B
The
launch
base
document
will
we'll
talk
more
about
the
launch
phase
here
when
we
get
to
talking
about
the
the
feed
document
we
had
submitted
this
document
to
the
isg
for
publication
and
Adam
does
have
it
and,
and
it
turns
out
that
what
it's
waiting
for
it
hasn't
moved
to
the
iesg
agenda
in
particular,
because
he
conducts
a
review
before
he
advances
the
document.
So
that's
actually
in
progress,
and
he
has
some
comments.
B
He's
gonna
in
questions
he'll
be
bringing
back
to
the
working
group
shortly
after
we
get
out
of
this
meeting,
but
it
also
turns
out
that,
as
a
result
of
the
feed
document
inter
meeting
that
we
had,
we
have
some
suggestions
for
this
particular
document.
So
we'll
get
to
that
discussion
later.
But
you
know
you
know
yay
for
us
for
submitting
a
document
for
publication,
but
we'll
just
have
to
deal
with
sort
of
some
minor,
last-minute
issues
here
as
we
go
along.
B
So
the
next
item
on
the
agenda
is
to
talk
about
the
the
extension
document
and
the
interim
meeting
that
we
had
with
respect
to
that
document
and
Roger.
We
will
go
over
to
you,
come
up
here
to
the
microphone
and
stand
in
the
pink
box,
so
the
Medeco
folks
can
see
you
and
while
you
talk
I'm
going
to
distribute
the
blue
shoes,
thank
you
good.
E
Afternoon
everybody,
the
feed
document,
is,
is
there?
We've
got
a
one
last
big
item
to
solve,
I,
don't
know
if
it's
big
or
not,
but
one
last
item
to
solve
and
that
deals
with
the
launch
phase
and
how
we
portray
launch
phase
depending
on
what
the
client
sends
in
so
originally
version.
5
draft
said:
if
no
launch
phase
was
passed
in
server
would
respond
with
I
think
our
on
subversion
5.
It
would
respond
with
all
active
launch
phases
and
in
our
interim
meeting,
which
we
had
Jim
last
week,
I
believe
we
had
8
people
participate.
E
It
was
great
a
great
turnout.
We
actually
discussed
the
launch
phase
piece
for
probably
about
45
minutes
straight,
going
back
on
the
pros
and
cons
of
each
of
the
possibilities,
and
we
spent
an
hour
just
on
virtual
meeting
and
me
coming
out
of
it.
I
thought
it
was
great.
We
actually
got
to
an
end
spot
where
we
think
this
last
piece
and
we
can
actually
push
this
draft
final
draft
through
and
get
a
working
group
last
call
on
it
soon.
So
again,
the
fee
document
piece,
the
last
remaining
question
and
I
think
it's
section.
E
Three
point
something:
three:
eight
three:
it
deals
with
the
launch
phase
and
it's
just
the
outstanding
questions.
I
posted
it
to
the
list
last
week,
I
don't
think,
there's
been
a
whole
lot
of
discussion
yet
on
it,
I
know,
Jody
posted
something
yesterday
or
this
morning,
something
about
on
it,
laying
out
the
four
possible
scenarios.
If
the
server,
if
the
claim
doesn't
pass
anything
server,
returns
an
error,
it's
something
that
I,
don't
think
the
group
really
thought
should
be
done.
The
other
option
was
if
the
client
does
not
pass
anything,
the
server
returns.
E
The
current
phase
the
problem
came
in
is,
if
there's
more
than
two
phase
two
or
more
than
one
phase
active.
Currently
what
happens
so
that
was
an
outstanding
question.
Do
you
then
return
an
area
because
you
can't
beside
or
do
you
pass
back
those
number
of
phases
back,
which
then
starts
to
get
a
little
more
verbose
that
some
people
didn't
really
want
to
get
into
I,
don't
know
if
there
was
a
third
option
or
not?
Oh
just
so,
it
was
passing
back
all
active
phases
and
then
they
got
discussion
around.
E
What
an
active
phase
was
this?
You
know
came
about
and
it's
is
anything
current
everybody
kind
of
agreed
on,
but
the
discussion
was:
if
there's
a
future
phase,
would
that
be
considered
active
or
not?
So
that
was
one
of
the
discussions
and
I
think
that
I,
don't
think
there's
enough
consensus
on
it.
I
think
if
we
can
get
launch
phase
updated
to
provide
the
listing
functionality,
I
think
that
the
current
should
be
just
the
current
in
that
future
is
my
thing.
F
This
gym
world
from
Verisign,
so
yeah
I,
look
at
the
the
notes
from
the
inner
or
median
and
I
reira.
Viewed
the
the
section
in
the
launch
phase
extension,
because
I
could
honestly
could
not
remember
multiple
active
phases,
so
I
looked
at
it
does
have
text
in
there
associated
with
supporting,
simultaneous
or
sequential
phases,
so
I
believe
that
was
feedback
from
the
list.
A
while
back
to
be
able
to
support
multiple
active
phases.
F
I
don't
have
a
specific
use
case
for
that
scenario,
you'll
be
good
to
know
whether
or
not
there
is
a
valid
use
case
for
simultaneous
active,
but
my
interpretation
of
active
would
be
current,
not
future
and
I.
Don't
I!
Don't
believe
that
this
would
be
a
big
deal
if
that's
a
corner
case.
Multiple
active
is
truly
a
corner
case.
Then
returning
back
multiple
active
fees
in
the
response,
I
think
it's
an
acceptable
solution,
but
I
believe
it's
a
corner
case
and.
F
Let
me
address
the
the
listing:
I,
don't
I,
don't
believe
a
listing
would
work
in
launch
phase
or
in
the
fee,
because
both
of
those
are
command
response.
Extensions
they're,
not
object
extensions.
This
is
better
suited
for
if
you're
going
to
provide
metadata
about
a
policy
or
policies
or
features
of
a
team
even
do
something
similar.
F
What
Verisign
has
done
in
our
proprietary
registry
mapping
extension
which,
when
you're
querying
for
information,
it's
going
to
come
back
and
says
here-
are
the
phases,
if
they're
overlapping,
so
be
it,
but
that's
not
really
what
the
launch
phase
extension
is
set
up
for.
So
this
is
an
extension
of
domain,
so
it
doesn't
doesn't
really
work.
I,
don't.
B
Want
to
gloss
over
that
to
do
lightly,
though
that's
actually
a
very
nificant
point
and,
and
those
who
were
part
of
the
p
extension
inter
meeting
that
we
had
I
know
I
really
need
to
know
what
other
people
think
and
what
you
want
to
do
about
this
issue.
You
know
from
my
point
of
view,
James
is
basically
saying
that
are
sick.
The
suggestion
out
of
that
group
to
put
the
the
functionality
into
the
launch
phase
document-
that's
not
the
right
place
to
do
it.
It
needs
to
go
someplace
else.
B
G
So
I'm,
not
sure
with
a
more
favorable
pass,
was
actually
to
ask
the
implementer
the
one
implementer
who
uses
it
in
that
way
why
he
actually
can't
use
the
classes
instead
of
that
yeah
and,
regarding
my
general
point
about
the
fee
extension,
my
requirement
to
the
change
to
the
document
is
that
the
fee
extension
must
work
on
a
registry
that
is
completely
unaware
of
launch
phases.
Yeah.
G
We
might
have
cases
out
there
and
we
are
running
a
ccTLD
registry
as
well,
and
we
don't
have
any
large
phases
there
if
we
ever
decide
to
do
premium
names
or
something
like
that,
we
want
to
use
the
feed
extension,
but
we'll
not
gonna.
Introduce
launch
phase
is
just
because
of
the
feeds
tension.
So
that's
my
basic
requirement.
However:
we
get
there.
I,
don't
have
a
super
strong
opinion,
I'm
just
worried
about
bending
the
standard,
because
the
implementation
choice
of
a
single
implementation,
yeah,
that's
what
I
also
said
it
so.
B
G
B
So
I
mean
what
I
recall
from
the
intra
meeting
discussion
is.
Is
you
you
thought
well
of
you?
You
did
want
to
move
that
particular
functionality
out
of
the
B
document
right,
the
the
idea
of
returning
all
the
valid
launch
phases
and
and
right
now
it
currently
works.
So
if
you
don't
give
a
launch
phase,
you
do
get
a
response,
yeah
and
I.
Think
all
of
that
meets
your
requirements
and
so
other
than
that
you
know.
Okay,.
G
I
just
want
to
avoid
the
misuse
of
the
launch
phases
for
for
an
application
use
case,
for
which
the
class
attribute
was
actually
intended
for
yeah
and
I
understand.
We
also
had
different
prices
to
in
sunrise
and
blah
blah
blah,
of
course,
but
like
introducing
hundreds
launch
phase
is
just
because
we
have
hundred
first
classes
is
not
the
right
thing
if
you
have
to
file
attribute
available
as
well.
What.
I
Jody
Jody
Coker
GoDaddy,
so
one
of
the
questions
that
I
had
is
at
times
during
a
registries
launches.
There
are
no
there's
no
phase
available.
For
instance,
it
could
be
a
quiet
period
between
sunrise
and
land
rush,
land
rush
and
GA,
or
any
of
the
other
faiths
that
you
could
have
so
during
that
time.
I
guess
what
I'd
like
to
try
to
figure
out
is
what
gets
returned
if
enough
launch
phase
is
sent
in
while
there
is
no
phase
available.
This
is
nothing
available
to
be
registered.
Then
that
kind
of
thing.
F
This
gym
goal
from
Verisign
I
would
say
you
know
if
there
was
a
gap
between
the
two
and
that
you're
not
accepting
registrations
at
that
point,
then
the
fee
would
not
come
back
with
anything
because
you
can't
register
at
that
point.
But
then,
if
obviously
rolled
into
let's
say
land
rush
or
claims,
then
it
would
return.
J
I
F
The
domain
name,
that's
good,
a
good
question:
we
don't
have,
we
don't
have
those
gaps
in
our
systems.
So
I
like
to
hear
from
one
of
the
other
registries
that
may
have
a
gap.
My
assumption
is,
it
would
come
back
as
unavailable
because
otherwise
it
will
then
fail
and
create
if
there's
not
an
active
phase.
So.
E
B
So
Jim
Galvin
and
just
to
clarify,
make
sure
that
I
understand
this.
It's
just
remember
your
discussion
that
we
had
before
yeah.
What
you're
saying
is
that
if
the
phase
is
not
active,
then
it's
not
available.
If,
if
a,
if
a
create
command
will
not
succeed,
then
it
has
to
be
indicated
as
unavailable.
That's
the
way
that
this
extension
will
work.
B
F
K
No
Chris
from
across
the
station
I
have
seen
both
some
registries.
Return
are
available,
some
return
available
and
then,
when
you
do,
they
create
there's
nothing
there.
It
doesn't
work
so
I,
I,
don't
know
what
that's,
if
that's
within
this
scope
of
what
we're
trying
to
do
with
this
extension,
though,
because
that's
up
to
the
registry
to
decide
what
they're
going
to
return
and
availability
and
can
we
force
them
with
this
extension
to
do
something
else,
I
I
would
I
would
assume
no.
B
We
could
provide
guidance,
Jim
Calvin
speaking
I
mean.
Obviously
we
could
I
mean
I,
don't
know
that
I
guess.
The
question
is
whether
it
should
be
a
must
or
a
should
I
think
my
going
in
position
would
be.
It
should
be
a
should.
You
know
that
the
way
you
should
behave
if
someone
asks
for
a
price
is
whether
or
not
you
say
it's
available
or
unavailable
should
depend
on
whether
a
create
would
succeed
or
fail,
and
we
could
make
an
indication
that
way
I
mean
as
a
registrar.
B
K
Think
I
think
it
should
be
available.
It
should
show
is
available,
but
it
should
have
some
cable,
yet
maybe
in
a
region
field,
something
that
one
space
is
not
because
the
domain
saying
it's
unavailable
could
mean
that
spread
to
serve
already.
So
how
can
we
tell
the
customer
why
this
domain
name
is
not
available,
so
we
need
both
the
availability
and
the
reason
behind
the
unavailability.
B
B
E
M
This
is,
this
is
a
loser.
I
think
we
should
tie
it
to
the
original
check
man
because
I
mean
that
is
what
we're
going
for
right,
we're
sending
a
check,
and
so
the
semantics
should
follow
the
you
know
the
original
so,
like
Scott
pointed
out
the
or
the
the
check
should
return
available.
There
equate
command
would
succeed
and
it
should
return
unavailable
if
it
won't
succeed.
So,
and
that
is
what
we
should
use
here
too.
If
we
shouldn't
you
know
this
extension
shouldn't
change
the
behavior
and
it
shouldn't
define
the
behavior
at
all.
M
I
So
I
guess
I
just
wanted
Jody
call
ker
from
godaddy
I
just
want
to
wrap
this
up
a
little
bit.
So
basically,
if
what
we
pass
in
and
the
check
command
is
going
to
be
used
to
create
the
domain
name,
that's
how
we're
going
to
determine
whether
it's
available.
So
you
have
to
have
the
correct
phases
on
it
all
they
correct
extensions
on
it
in
order
to
do
the
check
command
to
return,
whether
that's
available
or
not,
because
those
those
same
extensions
will
be
passed
in
with
the
create
command.
I
Yeah
absolutely
but
it,
but
you
at
least
need
some
extensions
for
some
of
these.
You
need
to
have
the
fie
extension
on
it
right
and
in
the
launch
phase
to
create,
for
some
of
these.
Oh
hang
on
I'm
sure
that
there's
registries
that
have
needed
to
launch
phase
on
there
in
order
to
register
the
domain.
D
F
No
I
would
I
would
suggest
that
I
would
suggest
that
I'm
sorry
I
apologize
if
the
phase
is
not
passed,
then
based
on
what
you've
defined
in
3.8
the
fee
extension
I.
Honestly,
don't
have
much
of
an
issue
with
that.
As
long
as
we
understood
what
multiple
active
phases
meant
right
and
if
a
future
phase
or
in
essence
a
future
phase,
was
desired,
then
the
the
registrar
could
go
ahead
and
provide
that.
I
F
B
Okay,
so
I
think
in
trying
to
bring
this
to
a
close
there.
There
are
still
two
I
think
you
understand
what
has
to
happen
here
with
all
of
this
right,
so
we're
good
at
that.
You're
gonna
provide
some
revised
text.
Yes,
question
that
I
have
those
do.
Do
you
believe
that
you've
heard
consensus
of
what
to
do
with
the
launch
phase
stuff,
because
I
heard
James
saying
it
shouldn't
go
into
the
launch
phase
document
as
document
editor
here
or
of
this
document?
E
Issue
forward,
yeah
I
think
that
we
still
have
to
decide
on
that
piece
of.
Where
is
that
going
to
come
from
because
I
see
I
think
that's
functionality,
that's
still
needed
and
people
don't
want
to
provide
it
in
the
fee
which
doesn't
seem
like
it
should
be
and
as
Jim
suggested,
it
doesn't
seem
like
it
fizzes
in
the
launch
phase.
So
where
are
we
going
to
put
that
piece.
B
F
Yeah
again,
I
I
believe
it's
a
corner
case
for
multiple
active
phases.
So
I'd
really
like
to
hear
a
specific
use
of
that.
So
in
essence,
saying
that
it's
needed
I
guess
I'm,
not
sure
if
I'm
in
agreement
that
it's
needed,
because
it
sounds
like
a
corner
case
and
then,
if
we're
gonna
go
down
that
path,
provide
the
information
around
phases,
then
we
should
think
of
it
more
generically,
not
just
about
phases
but
features
and
policies
as
well.
Well,.
E
Yeah
and
I
can
give
you
the
cases
when
you
do
a
pre-registration
you
pre-register
for
multiple
phases
and
you
need
to
know
what
those
phases
are
that
are
coming
up
so
that
you
can
pre-register,
because
you
may
pre-reg
for
sunrise
or
you
may
pre-register
chie.
But
if
you
don't
know
what
those
phases
are,
how
are
you
gonna
pre
write
for
those
well.
F
F
G
F
Other
information
as
well
similar
to
what
Varys
I
know
it's
already
created
in
our
proprietary
registry
mapping.
Extension:
okay,
take
a
look
at
it.
I
think
we've
already
posted
a
list,
I'll
post
it
to
list
again
take
a
look
at
it
and
see
whether
or
not
that
kind
of
information
which
includes
all
the
phases
by
the
way
would
be
applicable.
So.
B
B
B
If
you
recall-
and
we
had
quite
a
bit
of
discussion
about
this
and
in
our
last
session
about
generalizing-
this
object
to,
rather
than
being
a
reseller
explicitly,
let's
just
make
it
an
organization,
object
and
so
she's
here
to
tell
us
about
the
changes
that
she
made
is
as
part
of
moving
in
that
direction,
and
so
we
have
your
slides
here
and
and
I
will
just
say
next
slide
or
look
at
me
and
I'll
move
them
along
for
you.
Okay,.
N
And
hello,
everyone
and
today
I,
will
give
a
very
quick
updates
and
organization
extension
drops.
Actually,
we
have
discussed
reseller
gifts
for
many
times
and
we
the
working
group
and
also
have
many
opinions
about
the
reseller
direction.
You
know
we
have
the
four
listed
for
operation
options
at
a
so
I'd
have
media,
I.
Think
and
finally,
the
working
group
decided
to
do
a
new
object
organization
object
and
it
will
have
many
different
type
of
groups,
including
our
registrar
registry
and
reseller,
and
many
other
type
of
roads.
N
N
Okay
for
for
the
organization
extension
dropped.
The
modification
is
relatively
simple,
because
there
is
only
one
element:
ID
in
the
extension
part,
and
we
add
an
attribute
with
the
ID
element.
The
row
attribute
that
represent
the
relationship
organization
would
have.
The
values
are
defined
in
your
rovelli
registries
and
you
can
update
all
the
oils
next.
N
This
is
in
the
slide.
There
is
a
simple
info
response
example
and
the
ID
will
have
list
of
baroque
road
drugs,
such
as
with
a
lot
privacy
acts
privacy
of
proxy
next
and
for
the
organization
extension
thought,
and
we
have
some
new
elements,
including
the
ID
status
and
of
19
row
elements
with
two
sub
element,
and
one
is
a
type,
and
it
also
has
a
rope
status
attribute
and
the
other
sub
element
is
the
optional
Real
ID
this
grow
I'll.
N
The
element
is
defined
you
to
have
a
third
party
assigned
ID
such
as
de
ina
idea
for
a
registrar,
and
this
is
optional.
Choice
in
the
the
following
is
an
example
of
your
element
and
next
piece.
This
part
in
the
studies
about
the
Rovelli
I
mentioned
before
this
is
the
we
have
some
initial
weathers
are
defining
in
this
red
tree:
release
the
Registrar
reseller
and
the
privacy
proxy,
and
also
you
have
your
own
values.
It
could
give
us
feedback
and
we
can
update
this
part
next,
please
and
when
we
put
in
forwards
the
reseller
drops.
N
We
also,
we
have
many
comments
and
feedback.
Sound
Menenius
and
many
experts
talk
to
us
and
we
always
heard
about
the
why
reseller
is
important
them
registrar
or
some
other
row
rows
of
organizations.
So
at
the
time
we
change
it
to
a
generic
object
organization,
object,
extensions
and-
and
we
also
heard
about-
maybe
this
extension-
it's
a
little
complicated
and
we
tried
our
best
to
minimize
the
required
fuse.
N
There
are
only
seven
if,
for
just
a
one
thing,
the
type
of
organization,
if
you
just
extend
the
reseller
I,
think
maybe
you
can
identify
our
angry
seller
from
its
name.
Let's
have
four
mini
multiple
types
of
the
organizations
that
maybe
it's
a
little
difficult
of
us
to
just
to
identify
a
reseller
from
the
name,
so
I
think
it's.
N
B
An
important
consideration
for
the
working
group
is,
you
know,
is
this
document
now
in
a
place
where
it's
ready
to
move
forward
or
not,
and
so
one
question
that
I
have
for
you
than
the
dispute
have
any
work
in
your
mind
to
do
on
these
documents.
Now
we
kind
of
have
the
discussion
about
generalizing
its
organization.
Are
there
any
open
questions
in
your
mind
with
respect
to
these
documents.
N
Of
course,
in
my
mind
that
this
is
the
working
group,
discussion
and
many
actors
have
suggested
to
do
a
more
generic
opt
organization
object,
so
we
change
the
taxi
and
XML
formats
and
the
to
certify
all
these
three
comments,
and
also
we
have
some
requirements
to
extend
the
result
based
on
the
we
set
up.
We
also
have
many
other
road
types
of
languages,
so
I
think
we
like
to.
F
F
In
as
well
I'm
a
co-author
on
this,
and
we
work
together
to
come
up
with
this
based
on
the
working
group,
feedback
I
think
what's
needed.
Now
is
some
implementation
experience
and
my
proposal
would
be
for
the
registries
to
look
potentially
use
this
for
the
Registrar
information.
I,
don't
know,
it's
very
sounds
like,
for
example,
created
a
custom
extension
for
providing
Whois
information
to
support
transfers.
F
This
would
might
be
an
alternative
mechanism
for
registrar's
to
be
able
to
get
information
about
the
other
registrar
directly
in
line
without
going
to
who
is,
and
that
sort
of
thing
just
an
idea
of
getting
some
experience
in
using
this,
because
then
the
next
step
would
be
for
reseller
information.
If
the
registrar's
want
to
do
that,
so.
B
L
Well,
I
think
what
I'm
hearing
here,
oh
I'm,
sorry
Scott,
go
ahead.
You
Scott
Hollenback,
not
that
I'm
going
to
say
anything
counter
to
what
Jim
said,
but
what
I
would
suggest
that
in
terms
of
moving
forward
remember
implementation
is
not
a
requirement
right.
However,
there
was
a
recent
RFC
70,
something
something
something
that
describes
an
implementation
status
section
that
can
be
added
to
internet
drafts.
What
I
would
suggest
we
do,
then,
is
add
that
text
capture
everything
we
know
about
existing
implementations
and
move
forward
from
there.
Yes,.
B
B
So
I
think
the
status
of
the
document
is
to
bring
to
the
mailing
list
a
desire
to
learn
about
implementation
status
and
have
people
report
to
the
list
on
what
they
have
done
or
will
do
and
capture
all
of
that,
and
then
we
can
make
a
decision
about
when
to
move
forward.
Ideally,
if
we
can
find
at
least
two
people
who
will
put
an
implementation
status
and
there
of
actual
implementations,
then
I
at
least
do
and
I
would
say
we
we
can
much
more
comfortably
suggest
to
move
the
document
forward.
G
B
P
P
So
when
people
in
conflict
over
a
resource
they'll
be
able
to
see
whether
any
suspicious
changes
have
been
made,
20
of
the
relevant
records,
there's
a
more
enforcement
use
cases
so
being
able
to
see
who
controlled
an
IP
address
block
at
a
given
point
in
time
and
then
more
open-ended.
There
are
research
use
cases
as
well.
P
P
P
Ip
address
ranges
are
a
bit
different
compared
with
the
other
object
types
because
they
can
be
split
or
aggregated
over
time.
So,
for
example,
if
somebody
queries
for
24,
but
when
they
query,
the
only
object
that
exists
is
the
is
a
covering
22,
but
previously
that
more
specific
24
existed,
there's
an
argument
that
maybe
only
the
24s
history
should
be
returned,
or
perhaps
the
22
yeah.
So
it's
not
rather
than
try
to
I
guess
pick
one
or
the
other.
P
P
P
The
first
thing
here
is
to
the
public
history
service
that
opening
runs
at
the
moment.
The
second
is
to
the
backend
for
that
service,
and
the
third
is
a
rudimentary
front-end
that
allows
for
querying
and
seeing
objectives
over
time.
I
would
very
much
appreciate
any
review
and
feedback.
A
couple
of
open
issues
are
how
to
handle
redirections.
P
So
in
the
numbers
space
where
an
IP
address
block
has
moved
from
one
registry
to
another,
there's
a
question
about
how
to
best
represent
that
in
in
this
document
and
then
we're
coming
at
this
very
much
from
a
number
perspectives.
So
if
there
are,
there
are
probable
issues
around
forward
demands
that
we're
not
thinking
of
so
any
feedback
along
those
lines
would
be
great
as
well.
B
Let
me
just
take
a
moment
to
remind
folks
in
the
working
group
there's
almost
always
a
few
new
people
around,
so
the
registration
extensions
working
group
actually
serves
two
roles.
One,
of
course,
is
to
process
any
kind
of
document
in
the
registration
extensions
area
which
applies
to
both
EPP
and
our
DAP
thinks
I
want
to
go
on
to
the
standards
track.
So
we
have
that
role
in
conducting
that
review
and
adoption
and
then
moving
it
through
the
the
formal
process
for
all
of
that.
B
In
addition,
this
the
working
group
and
the
mailing
list
in
particular,
is
open
and
available
for
anyone
with
a
related
document
who
is
looking
for
appropriate
expertise
to
get
some
review.
There
is
an
explicit
use
case
for
this,
which
is
the
Ayana
registry
of
EPP
extensions.
These
are
not
required
to
be
internet
standards,
so
people
can
certainly
create
extensions
which
they
can
then
simply
ask
to
get
listed
in
that
registry,
which
is
always
allowed.
B
There
is
a
a
technical
review
that
happens
to
items
that
go
into
that
registry,
mostly
just
for
self
consistency,
and
if
any
conflicts
exist,
but
folks
are
used.
This
mailing
list,
the
mailing
list
for
this
working
group,
is
used
as
the
contact
point
for
people
who
submit
a
request
to
a
Ana
to
get
on
that
registry.
So
they
get
reviewed
by
this
working
group.
Scot
Hollenbeck
actually
leads
the
the
team
of
people
who
are
responsible
for
those
documents,
but
in
any
case
we
encourage
these
kinds
of
things.
So
I
just
want
to
make
that
clear.
B
He's
allowed
to
come
here
and
say
you
know
this
is
not
for
adoption
yet,
but
he
is
looking
for
some
review
and
comments
from
he's
in
this
group
and
there's
no
one
jumping
up
to
the
mic,
who
seems
to
want
to
say
something
but
I
do
you
know
you're
encouraged,
please
to
continue
on
the
mailing
list
press
on
the
document
and
we'll
try
to
move
this
forward
if
and
when
you're
ready
to
ask
for
adoption?
Well
we'll
take
that
step
to.
B
Okay,
so
that
takes
care
of
actual
active
technical
work
at
the
moment.
So
this
is
a
a
slot
in
the
agenda
where
the
co-chairs
would
like
to
walk
down
each
of
the
other
documents
that
have
milestones
in
our
in
our
Charter
and
on
our
milestone
list
and
on
the
data
tracker
and
give
a
quick
discussion
about
each
of
the
authors
of
these
documents
was
asked
to
come
up
to
the
mic
one
at
a
time
and
just
take
a
couple
of
minutes
to
give
their
version
of
two
minutes
of
what's
the
next
step
on
their
document.
B
So
what
we
want
to
do
as
as
the
chairs
is,
we
are
looking
to
make
sure
that
the
milestones
are
still
listed
in
the
order
that
are
interesting
here.
So
this
is
your
opportunity
to
hear
about
these
documents.
Make
sure
that
you
see
what's
coming,
they
are
listed
here
in
the
order
in
which
they
are
milestones,
probably
would
have
been
helpful
to
pull
the
dates
forward
onto
the
slide,
I
suppose
to
remind
people
what
they
are
on
the
milestone
list,
but
I
think
we
want
to
make
this
a
regular
part
of
our
agenda
here.
B
B
If
anybody
has
anything
about
any
one
of
the
documents,
if,
if,
in
particular,
if
you
want
to
speak
to
saying
that
a
document
should
move
up
in
the
priority
list,
you'd
like
to
see
a
reordering
of
these
documents
and
reordering
of
the
work
we'd
like
to
hear
that
recall
from
Chicago,
we
actually
did
a
review
of
all
of
our
milestones.
We
made
a
presentation,
then
we
had
built
up.
The
co-chairs
had
built
up
in
working
in
the
background
with
document
authors,
the
milestone
list,
we
made
a
presentation
to
the
working
group
which
was
generally
agreed.
F
Yes,
so
for
the
change
poll,
the
latest
revision
was
to
change.
The
authorship
Sharon
had
left
new
star
SoCal
volunteer
to
take
co-authorship
on
behalf
a
new
star
for
this
particular
draft
and
the
latest
revision
as
well
added
the
implementation
status,
information
for
Verisign
and
Cal
intent
risk
al
here
we
go
Cal
is
going
to
add
the
implementation
status
from
new
star
to
the
craft
as
well
as
far
as
this
particular
extension
is
concerned.
This
is
completely
generic.
F
I
highly
encourage
the
registries
to
review
this,
to
consider
this
for
any
suicide
changes
that
are
occurring
and
I
encourage
the
registrar's
to
express
the
value
of
this
extension,
because
I
know
that
this
was
built
for
the
registrar's
to
be
able
to
more
easily
reconcile
things
that
are
occurring
in
the
registries.
So
the
more
this
is
used,
the
easier
it'll
be
registered.
Ours
be
able
to
be
proactively
notified
of
changes
occurrence
of
their
objects.
F
E
Miss
Roger
and
I'd
like
to
promote
Jim's
suggestion
of
registries.
Looking
at
this
as
a
registrar,
we
would
love
to
see
registries
implement
this.
We
would
we've
been
pushing
this
for
quite
a
while
and
I
thank
Jim
for
putting
this
on
the
list
to
get
done.
But,
yes,
we
definitely
look
forward
to
this
being
completed
so
hurry
up.
B
F
B
E
F
F
Use
of
this
particular
extension,
but
its
original
intent
was
to
be
able
to
support
oxygen
off
of
domain
names
by
third
parties
and
allow
for
the
allocation
be
passed,
grew
from
the
Registrar
that
could
be
compared
on
the
registry
to
authorize
the
allocation
of
a
domain
name,
but
there
are
so
many
other
use
cases
that
we've
seen
for
this.
So
to
answer
your
next
question,
which
is,
it
is
absolutely
stable.
F
It's
as
simple
as
you
can
get
I'm,
just
passing
a
string
a
token
across
from
the
registrar
to
the
registry,
but
where
the
complexity
comes
in
is
what
is
the
form
of
the
token?
You
can
have
many
different
use
cases
on
this.
It
could
be
a
string
to
be
a
encoded
block
of
XML
could
be
just
about
anything.
The
point
is
that
you
need
to
be
able
to
pass
this
information
from
the
registrar
to
the
registry
to
be
able
to
allocate
a
tomato.
O
B
Q
Hi,
so
a
few
months
ago,
we
thought
we
were
pretty
close
to
being
done
on
this,
but
a
few
new
things
have
have
come
up,
so
we've
got
a
few
small
changes
that
are
gonna
be
going
into
the
draft.
Jacques
letoure
ran
a
panel
at
the
last
ICANN
meeting
on
policy
impacts
of
C
D
s
and
C
DNS
key
records
and
they're
there.
Q
Q
This
is
essentially
can
only
be
done
by
the
registrar's,
but
there
was
a
bit
of
research
done
into
the
contracts
and
it
shows
that
the
what
it
says
about
registries
is
they
will
accept
DNS,
DNS,
SEC
material
according
to
industry
practices,
but
not
from
whom
and
the
the
registrar's
contract
said
they
will
relay
DNS
SEC
material
according
to
industry
practice,
but
it
doesn't
make
it
their
exclusive
responsibility.
So
this
doesn't
have
a
huge
impact
on
what's
in
the
draft,
but
it
does
change
who
can
implement
very
significantly.
Q
Q
So
we
had
some
comments
from
Mark
Elkins,
suggesting
that
we
adopt
some
of
the
things
that
were
used
by
is
see
in
bootstrapping
DNS
in
there
dlv
system.
One
thing
that
looks
particularly
useful.
There
would
be
inserting
a
record
in
the
registries
zone
that
indicates
the
entry
point
for
the
for
an
API.
Q
Q
Q
So
our
current
plans
are
to
produce
a
new
version
of
the
draft
I'm
hoping
within
the
next
couple
of
weeks,
once
we
sort
of
sort
out
among
ourselves
how
the
these
new
changes
affect
things
and
we're
hoping
really
for
more
comments
on
the
draft,
and
one
made
some
great
comments
that
we
need
to
incorporate.
But
if
anyone
has
any
further
comments
related
to
what
he
had
to
say
or
anything
of
their
own,
we
would
really
like
to
hear
it.
F
I
was
like
I
thought
that
it
was
something
where
the
registries
were
going
to
start
pulling
information
out
of
DNS,
but
then
the
restful
calls
to
be
able
to
go
ahead
in
Ishi,
eight
actions,
yeah
I'm,
assuming
is
on
the
registry
side,
I'm,
not
sure
or
the
registrar,
so
I'm,
not
seeing
that
I'm,
not
it's,
maybe
and
I
haven't
reviewed
it
in
enough
detail.
Okay,.
Q
Q
Might
be
able
to
make
that
clearer,
the
the
intention
was
that
the
protocol
could
be
implemented
at
the
registry
or
the
registrar.
We
have
a
section
in
the
the
most
recent
version
about
it.
I
think
we've,
we
chose
a
distinct
phrase
to
refer
I
think
was
registration
agent
to
and
which
we
defined
as
being
either
the
registry
or
the
registrar,
whoever
it
is.
Q
Who
has
the
closest
business
relationship
which,
with
the
registrant
and
and
sort
of
indicate
that
that
that
that's
the
place
where,
where
this
is
intended
to
be
implemented,
and
that,
if
that's
the
registrar
that
they
would,
they
would
be
doing
all
this
work
and
then
passing
information,
for
example
through
upp
up
up
to
the
registry.
So,
but
we
can
probably
put
something
in
there
to
make
the
workflow
a
little
little
clearer.
B
So
Jim
Calvin,
let
me
insert
myself
into
the
queue
while
I'm
sitting
here,
but
not
wearing
a
hat,
so
Jim
Gallagher,
filius
I.
You
know
I
I,
appreciate
that
you
folks
had
done
the
detailed
analysis
of
contracts
and
determining
you
know
who
is
allowed
to
do
something
and
who's,
not
from
a
technical
point
of
view.
You
know.
All
of
that
is
true
and
I
agree
with
all
of
that
I.
B
Just
since
I've
been
the
one
who's
been
pressing
on
this,
a
lot
with
with
with
you
folks,
not
you
specifically
but
but
Oliver
and
shock,
and
others
just
feel
compelled
to
continue
to
to
go
on
record
and
point
out
that
part
of
Industry
best
practices
is
the
relationship
that
registrar's
and
registries
have
with
each
other.
Of
course,
there
is
a
question
of
documentation
on
all
of
this,
but
in
principle
the
standing
industry,
best
practices
registries,
don't
tell
registrar
its
what
the
data
should
be
registrar's
own
the
data.
B
So
the
idea
that
a
registry
would
take
in
these
DES
records
and
this
key
information
and
then
push
it
back
to
the
registrar,
is
you
know
not
a
foregone
conclusion
and
I?
Don't
know
if
you
know
any
registrar's
in
the
room
want
to
stand
up
and
speak
to
this
in
particular,
but
you
know
I
mean
my
experience
with
other
stars
is
no
they're
not
interested
in
that,
at
least
on
the
d
TLD
side.
But
if
we
can
change
that
that'd
be
fine.
Yeah.
B
As
an
individual
I
mean
I
I
think
it's
great
vertical
I,
certainly
don't
have
any
issues
with
it
and
I
I.
Think
it's!
You
know
it's
fine
piece
of
work,
but
I
am
very
concerned
about
the
policy
side
of
it.
So
where
my
registry
service
provider
at
I
just
have
to
stand
on
that
particular
principle,
yeah.
Q
L
I
G
H
L
R
And
my
name
Chan
Khong
y'all,
so
I
found
the
registration,
yeah
meeting,
I'm,
not
sure
they're.
The
counties
are
according
the
double
D
discussions,
there
are
three
Eponine.
First,
let's
treat
strict
bundling.
Second,
is
a
partial,
open
online
surveys.
The
responding
Cardinal
document
is
most
folks
on
straights
paneling.
This
paneling
is
required.
Most
of
the
restraints
share
the
same
a
lot
of
attributes.
So
currently
we
have
ohk
dossier
on
at
out
room
war
on
a
moto
g
SG
and
out
he
W.
So
a
lot
also
a
lot
of
the
Chinese.
R
Sentiment
so
we
already
have
a
lot
of
experience
here
so
meeting.
We
may
we
have
some
sample
proposal.
We
have
murder,
also
both
partial
so
has
hassle
boundary
and
a
strict
paneling
and
less
fun
in
together
with
a
uniform
solution.
But
after
several
discussion
we
cannot
easily
get
a
uniform
solution.
R
B
Okay,
so
just
a
quick
comment
on
the
history,
this
document
just
to
remind
the
working
group
with
when
this
document
was
originally
brought
forward.
We
actually
I
guess
it
was
to
ITF
meetings,
go
so
I
guess
it
was
Sol.
We
had
the
bath
on
DNS
bundling
and
we
had
decided
in
this
working
group.
We
put
this
document
on
hold
at
the
time
pending.
What
would
happen
in
that
particular
working
group
Athena's
bundling.
B
So
there
was
an
opportunity
there
for
all
bundling
parts
to
go
into
a
separate
working
group
so
that
we
had
that
bath,
but
there
was
no
follow
on
proposal
for
a
working
group.
So
now
we're
just
putting
this
document
we're
taking
this
document
off
of
a
hold
status.
If
you
will
kind
of
our
own
internal
designation
and
putting
it
on
the
list,
it
is
at
the
end
of
our
milestone
list
at
the
moment.
So
it's
not
something
which
is
going
to
come
up
here
in
in
the
near
term,
but
I
think
I
just
heard.
B
S
B
B
B
O
B
C
R
No
special
thing
about
your
nation
state,
her
Spada
in
osg
I'm,
not
out
he
wo
da
mo
all
implement,
has
this
mechanism.
So
we
also
have
a
CDN
say
table.
We
have
all
maintained
the
table
for
more
than
10
years,
so
I
Singapore,
especially
useful
Chinese
Tommy
names,
so
I
yeah.
It
is
okay
for
us,
a
lot
of
Chinese
Tommy
Quixote's,
also
a
lot
of
the
Chinese
young
names
and
the
second
night
here
and
under
and
the
so
I
asked
a
Tod.
R
B
I
think
at
least
one
action
that
should
come
out
of
this
is
to
collect,
implement,
put
a
particular
question
on
the
mailing
list.
You
should
ask
on
the
mailing
list
or
if
you
know
the
answer
you
can,
you
can
just
create
it,
but
ask
for
implementation
status
and
gather
that
up
and
create
that
section
in
the
document.
Okay
and
collect
that,
so
that
we
have
that
data
James
guy,
please.
F
And
as
Jean
grew
up
from
Verisign,
so
just
to
clarify,
there
are
three
forms
of
bundles:
one
was
Association,
so
we're
gonna
go
object-oriented
here,
its
association
was
pretty
much
client
specified
relationships.
The
next
level
was
aggregation
where
they're
separate
actual
instances
that
may
share
some
by
policy.
S
Ning
from
scenic
base
song,
the
RFC
three,
seven,
four
three
and
the
Chinese
domain
name,
if
one
register
your
preferred
Chinese,
dome
name
and
based
on
the
the
Chinese
domain
name,
we're
in
the
table
and
the
registry
will
then
also
then
do
the
simplify
the
domain
names
and
also
the
traditional
version
of
Domino.
So
that
means
all
the
registries
who
sell
who
sell
the
Chinese
domain
names.
T
B
Yeah
so
I
think
at
the
moment,
then
the
the
right
action
we
do
need
to
make
a
decision
about
how
and
when
to
change
the
milestones.
I
think
what
I'd
like
to
propose
is
that
we
take
that
to
the
mailing
list
that
question
so
that
we
can
allow
some
other
discussion
I'm
going
to
presume
right
up
front
that
most
people
probably
don't
have
that
closer.
Look
at
the
milestone
list,
so
we'll
construct
a
question
for
the
mailing
list.
B
The
chairs
will
construct
a
question
for
the
mailing
list,
with
the
dates
on
the
current
milestones
that
are
there
and
give
us.
So
the
workgroup
has
all
that
information
right
in
front
of
them
and
then
ask
the
explicitly
the
question
of
whether
folks
want
to
move
this
up
or
what
they
want
to
do
next
after
the
documents
that
are
in
progress.
Okay,
we're
not
going
to
take
on
the
work
item
anyway
until
we
discharge
a
couple
of
the
open
ones.
B
O
B
So
next
up
is
the
validate
draft
back
over
to
Roger
leet.
This
is
actually
the
last
one
right,
oh
I,
you
know,
I
I
should
actually
offer
just
as
a
as
a
point
of
clarification.
This
is
an
interesting
oversight
that
has
carried
forward
from
when
this
was
the
EPP
extensions
working
group,
because
this
document
actually
has
its
origins
as
part
of
the
original
chartering
of
EPP
extensions
and
coming
forward,
and
what's
interesting,
is
in
preparation
for
this
meeting
you're.
B
Their
co-chairs
discovered
an
interesting
gap
in
doing
an
audit
on
the
milestones,
and
that
is
that,
while
this
is
a
an
accepted
and
adopted
document
on
the
list,
there
actually
is
no
milestone
for
it.
The
milestone
is,
is
currently
missing,
which
is
kind
of
interesting.
I
have
actually
spoken
to
our
area
director
about
this.
So
he's
aware
of
this
and
then
and
in
recognition
of
the
fact
that
this
actually
did
come
with
us
from
way
back
in
EPP
extensions.
B
We're
gonna
submit
a
milestone
for
this,
and,
and
he
will
approve
that
and
allow
it
to
get
on
the
list
so
that
it's
part
of
what
we're
dealing
with
and
we
have
not
actually
decided
exactly
where
and
the
list.
This
will
go
right
now,
it's
at
the
end
and
at
the
bottom
and
and
we'll
have
to
figure
out
exactly
where
we
think
it
ought
to
go.
B
So
if
you
have
any
advice
about
that,
we'll
sort
of
take
that
question
to
the
mailing
list,
but
we
can
we
can
make
all
of
that
happen
in
the
our
area.
Directors
ready
for
that
I
mean
I'm
betting,
that
no
one
actually
noticed
that
right.
Anyone
here
actually
notice
that,
besides
us
and
we're
along
the
way,
but
anyway
interesting
Roger.
E
Over
to
you,
okay,
they
validate
is
a
mapping
to
validate
contacts
into
a
registry,
pre
transformation
command
so
that
you
can
get
a
valid
set
of
contacts.
Be
it
one
for
whatever's
needed
for
the
registry
to
be
validated
before
you
actually
issue
the
create
command
that
will
end
up
failing,
because
you
can
create
a
completely
valid
contact
at
a
registry,
but
you
can't
use
it
as
a
registry.
You
can't
use
it
as
an
admin
specifically
so
they'll
allow
the
contact
crate
to
happen
and
they'll
fail
the
create
domain.
E
So
this
actually
tests
that
prior
to
a
crate,
so
that
you
can
actually
get
a
valid
set
of
contacts
going
in
this
document
is
fairly
simple.
Straightforward,
I
think
it's
only
seven
pages
with
title
and
index
everything.
So
it's
it's
it's
a
quick
read
status
is,
is
it's
it's
done.
It's
been
through
several
comment
periods,
not
comment
periods,
but
several
iterations
and
right
now
it
just
sets
in
waiting
for
to
get
bumped
up.
B
Okay,
so
you
consider
the
document
staple
and
ready
to
go
forward
and
pending
any
other,
any
issues
that
might
surface
you're
ready
for
it
to
move
up
on
the
list.
Yes,
okay,
thank
you.
Thank
you.
Okay.
That
takes
us
through
that
and
moocs
us
onto
the
are
def
object
tag
in
this
case,
I,
don't
think
I
was
looking
for
Scott
to
say.
Anything
here
is
really
just
a
reminder
and
I
think
you
probably
at
this
point
you
know,
heard
everything
we're
saying
about
adoption.
B
Having
talked
to
our
area
director
folks
will
remember
from
the
Chicago
meeting
that
when
this
document
came
up
and
it
was
presented
there
and
we
talked
about
it,
although
there
seemed
to
be
in
the
room,
it's
time
some
consensus
to
adopt
this
document,
the
area
director
had
pushed
back
and
had
asked
instead
that
we
really
have
to
get
our
long
list
of
milestones
under
control.
So
one
of
the
things
that
has
happened,
as
you
know,
is
we
have
actually
trimmed
the
set
of
milestones.
B
So
now
it's
because
we
actually
dropped
a
couple
of
documents
off
along
the
way
here
when
they've
been
reordered
and
so
and
we
have
actually
submitted
the
launch
phase,
but
it
hasn't
moved
forward
on
to
the
is
GQ.
The
feed
document
is
just
about
ready
to
go
too
so
we'll
get
past
that,
but
the
explicit
guidance
from
our
area
director
is:
let's
move
along
the
work-in-progress,
a
couple
of
items
that
are
work
in
progress
and
as
soon
as
those
are
actually
on
the
isg
agenda
and
they're.
B
Actually
in
the
publication
cycle
itself,
then
we
can
come
back
and
adopt
this
document
and
add
it
to
our
list,
and
you
know
pick
up
some
of
the
other
milestones
and
move
it
along.
So
it
has
to
remain
pending
until
we
close
on
some
of
the
other
items
that
are
there.
That's
just
a
procedural
point,
more
than
anything
any
comments
or
questions
about
that
Scott.
Please,
oh
microphone.
D
L
Okay,
so
just
one
thought
there
we
know
fairly
well
that
within
a
few
months
we're
going
to
start
seeing
our
deaf
implementation
in
pilot
phases
among
gTLD
registries,
for
those
of
us
who
are
in
the
room
and
who
care
about
this
I'd,
really
like
you
to
take
a
look
at
this
draft.
If
you
are
going
to
be
implementing
support
for
contacts
in
our
depth,
this
document
describes
an
operational
practice
for
how
to
tag
them
in
a
way.
That's
consistent
with
existing
practice,
that's
being
done
by
the
our
IRS
today.
L
It
will
help
with
the
bootstrapping
of
contact
queries
if
you
think
that
that's
a
problem
right
and
if
you
do
take
a
look
at
it
if
you
start
to
implement
our
DAP
and
a
pilot-
and
you
think
this
is
helpful-
please
let
me
know
I
would
like
to
keep
the
document
alive
and
active
in
terms
of
adding
implementation
status,
information
right
and
indeed
once
this
finally
does
get
adopted.
There's
not
a
lot
here
in
terms
of
controversy
or
it's
not
protocol.
It's
BCP!
L
B
Okay,
then
we're
moving
towards
the
end
here.
So,
okay,
now
Roger
you
can,
you
can
get
up,
and
so
let
me
just
give
a
little
little
preamble.
We
we
had
the
interim
meeting
last
week
and
actually
I
I
have
to
say
that
even
from
my
point
of
view
was
really
was
a
very
successful
meeting
and
you
know
riders
already
indicated
he
thought
it
was
successful.
You
know
certainly
interested
in
and
anyone
else
who
was
there.
B
This
really
did
was
a
nice
complement
to
that
opportunity
and
it
focused
on
one
single
document.
So
unless
anyone
has
any
objections
to
whether
or
not
you
know
we
should
do
this,
I
think
that
having
inter
meetings
going
forward
is
a
good
thing
now.
This
was
kind
of
an
experience
even
for
for
your
co-chairs
to
learn
how
to
make
all
of
this
happen
in
and
understand
all
the
administrative
process
that
that
gets.
It
gets
it
going.
We
think
we've
got
all
that
under
control.
B
We
have
learned
one
thing
along
the
way
that
we
didn't
know
before
which,
for
this
particular
meeting,
godaddy
was
kind
enough
to
host
it
as
a
zoom
meeting
and
that
that
worked
out
for
all
the
participants
and
no
one
objected
to
using
that.
But
it
turns
out
you
can
ask
for
Miguel.
You
know
we
can
use
the
IETF
sort
of
standard
for
doing
these
things,
so
we
can
actually
make
a
meet
echo
request
and
then
have
that
set
up
so
that
we
can
use
that
and
everybody
can
be
remote
and
we
can
have
a
meeting.
B
So
that's
just
something
to
keep
in
mind
it's
it's
certainly
not
a
requirement.
I
mean
zoom
worked
out
well
and
I.
I.
Think
that
you
know,
just
speaking
from
the
point
of
view
of
a
chair,
whatever
technology
works
for
the
participants
is
fine
for
the
interim
meeting,
it's
just
useful
to
know
that
that
option
is
available
to
us.
B
B
So,
but
there
is
the
open
question
here
for
the
working
group
as
to
whether
you
know
these
I
inter
meetings
are
so
effective,
you
know:
do
we
really
need
to
plan
for
two
meeting
requests?
The
IETF
tends
to
want
to
discourage
that
unless
you
can
really
justify
it,
I
think
we
did
a
good
thing
last
time
and
justifying
it.
It
helped
this
working
group
a
lot.
This
working
group
tends
to
be
a
little
slow,
moving
a
little
hard
to
keep
people
engaged
and
active.
B
B
B
The
only
real
thing
that
you
have
to
do
is
is
ask
on
the
list,
if
there's
interest
in
having
a
meeting
and
as
long
as
we
know
at
least
two
weeks
in
advance,
so
that
at
least
one
week
in
advance
that
we
can
submit
all
the
formal
documentation
to
the
IETF
for
it
and
get
it
listed
in
the
in
the
data
tracker.
As
a
meeting
that
occurred,
then
it
can
happen.
So
you
really
just
need
to
drive
it.
If
you're
a
document
editor,
you
want
to
move
along
a
document.
You
really
can
just
drive
this.
B
Just
you
know
make
sure
that
your
your
chairs
are
informed
and
tracking
with
you,
because
we'll
do
the
administrative
side
of
working
with
the
Secretariat
to
get
everything
together
and
happen.
But
this
is
an
opportunity
for
open
discussion.
People
have
an
opinion
about
inter
meetings
not
having
them
Roger.
Do
you
want
to
say
anything
more
about
you
started
to
say
before
I'll
give
you
a
chance
that
you
ran
this
meeting
and
pushed.
E
Yeah
this
Roger
I'm,
not
sure
I,
have
anything
much
more
to
say
what
I
said:
I
it
was
very
useful.
We
had
eight
or
nine
people
attend
and,
as
Jim
mentioned,
we
worked
through
some
pretty
good
items,
actually
a
pretty
quick
pace
and
that's
why
I
would
still
suggest
trying
to
get
a
face-to-face
meeting
here
that
that
virtual
meeting
was
nice
because
we
were
sort
of
face-to-face
and
it
seems
to
work
better
than
emailing
and
waiting
for
someone
to
respond.
E
B
Thank
you
vet,
but
just
my
takeaway
from
from
that
is,
is
you
want
to
leave
open
the
question
of
a
second
work
session
at
the
next
meeting?
Let's
not
lose
track
of
that,
but
definitely
promoting
inter
meetings
and
doing
it
again
so
document
authors
keep
that
in
mind.
We
can
move
things
along.
Okay,
any
other
discussion
or
comments
from
anyone
about
inter
meetings.
B
L
My
please
go
ahead:
it's
got
Hollenbeck.
This
is
a
good
thing.
We've
got
other
things
to
talk
about,
okay,
so
those
of
you
who
are
at
the
meeting
in
Chicago
or
saw
them
mean
the
meeting
minutes
me
recall
that
I
had
asked
a
question
about
an
individual
submission
internet
draft
that
was
written
by
myself
and
two
of
my
colleagues.
It
describes
a
method
for
doing
search
in
our
DAP,
using
regular
expressions,
one
of
the
bit
of
feet.
One
of
the
bits
of
feedback
we
got
was
now
don't
do
base64
URL
encoding.
L
You
can
just
use
standard
URL
encoding
and
we
investigated
that
found
out
that
it
works
just
fine.
So
the
document
was
updated
to
reflect
that
change.
However,
one
of
the
other
things
I
took
away
from
that
meeting
when
I
asked
for
who
might
be
actually
interested
in
using
this
pursuing
it
or
whatever.
There
was
absolutely
no
response
at
all,
so
I
don't
want
to
work
on
something
that
people
have
no
interest
in,
and
so
I
just
wanted
to
ask
one
more
time
before
we
kind
of
let
this
one
die.
B
U
G
V
I'm
Arianna
Freda
from
registered
IT
I
would
like
to
present
in
a
couple
of
minutes
an
idea
about
to
improve
interoperability
between
our
clients
and
server,
and
I
would
like
to
know
if,
in
your
opinion,
it's
worth
to
be
developed
and
presented
in
a
draft.
The
idea
is
based
on
the
G
zone.
Schema
concept,
which
is
a
schema,
is
described
in
free
internet
draft
of
JSON
beasts
working
group,
and
it
defines
amid
the
media
type
application.
/
schema,
plus
Johson
ageism
based
the
format
for
describing
the
structure
JSON
data
it
asserts.
V
V
Current
inna
ended
up.
There
is
a
no
way
for
the
server
to
provide
the
formal
description
of
its
feature.
There
is
a
delta
and
the
point,
but
it
returns
a
human
readable,
but
not
machine
precious
ball.
Information
and
such
such
information
can
be
material
genius.
The
server
cannot
provide
for
my
information
about
which
adapter
query
capabilities
implement
and
which
subset
of
the
standard
response
or
or
which
response
extensions
it
returns.
V
So
the
client
cannot
configure
itself
according
to
the
server
feature
and,
as
a
consequence,
the
user
can
waste
time
to
submitting
submit
request
that
cannot
be
accepted
because
they
are
not
implemented
at
all
or
because
they
are
not
allowed
the
core
the
tool
they
use
the
richest
level.
The
client
must
know
the
feature
of
all
the
service
int.
It
interacts
with
if
a
server
changes
its
feature
Disco's
and
additional
implementation
effort
by
the
client
implementers.
V
B
V
B
W
Is
an
errand,
so
I
have
a
trap.
It
may
have
expired
already
on
describing
the
are
tab.
Data
structures
in
JC
are
not
json
schema
and
I'll.
Note
that
both
JCR
and
Jason
schema
are
not
standards
or
IETF
that
there
are
ITF
drafts
for
both
of
them,
but
the
IETF
don't
work
with
both
the
so
as
far
as
trying
to
put
the
Jason
Jason
that
are
diffuses
into
a
more
formal
structure
or
a
more
formal
schema
definition.
I
think
is
an
interesting
idea.
W
Obviously,
since
I
wrote
a
draft
about
it,
the
I
do
have
a
problem
with
the
issue
of
clients,
somehow
understanding,
either
JCR
or
Jason
schema
and
then
adapting
their
behavior.
That
I
mean
that
idea
has
been
around
for
a
long
time.
The
people
who
did
soap
and
those
type
of
things
that's
one
of
the
things
they
sold
us
on
it
I,
don't
think
that's
a
good
path
to
go
down.
So
when
we're
talking
about
interoperability,
yes,
I
think
it's
a
good
idea
to
have
a
more
formal,
formal
definition
of
what
those
structures
are.
W
But
if
we're
doing
that,
because
we
think
clients
are
going
to
somehow
change
their
behavior
I
think
that's
a
false
expectation.
So
I
do
want
to
point
out
that
our
DEP
currently
does
have
the
part
up
conformance
structure
in
the
very
top
of
the
response
which
says:
here's
what
these
servers
do
support
so
before.
B
W
Hope
we're
talking
about
specifically
about
our
tap
and
not
Jason
schemes,
easy
yeah.
No,
this
is
probably
the
appropriate
forum.
If
there
are
interoperability
issues
with
our
deaf
people,
writing
clients
and
servers,
then
yeah.
This
is
probably
the
place
to
do
it,
and
if
we
want
to
go
down
this
path
of
trying
to
write
a
more
formalized
schema
around
it
yeah.
So
this
would
be
the
place
to
do
it.
I
don't
know
what
what
I
don't
know
is
how
many
other
people
are
interested
in
it.
You
have
two
so
far
right
so
so.
B
L
I
think
well,
Scott,
please
go
ahead.
Scott
Hollenbeck,
yeah,
I'm,
surely
interested
in
it.
I
mean
I,
see
some
value
to
it.
Both
Andy
and
Mario
are
saying
and
Andy.
You
might
just
have
been
a
little
bit
Heather
initially,
but
I
do
think
it's
interesting
now
that
we've
had
two
people
independently.
You
know
kind
of
come
up
with
the
same
idea
here
so
I
wouldn't
want
to
just
reject
this
out
of
hand.
I
think
it's
something
that
is
worth
discussing.
B
So
yeah
back
in
into
the
spirit
of
the
purpose
of
this
working
group
in
in
you
know
again
two
roles.
One
is
also
an
opportunity,
for
you
know
people
to
bring
interesting
topics
and
ideas
to
to
an
appropriate
set
of
experts.
Let
me
suggest
Mario
that
actually
you
should
write
an
internet
draft.
It
can
be.
B
You
know
an
individual
submission
for
right
now
and
then
make
it
visible
to
this
working
group
and
ask
for
comments
and
then
similarly
I'll,
look
back
the
nd
check
on
the
status
of
your
document
and
resurrected
if
necessary,
and
also
you
know,
when
the
two
of
these
come
out
together,
make
them
both
visible
together
and
then
the
working
group
we
can
reconsider.
I
mean
if
you
guys
both
want
I'm
sure
we
can
make
time
and
our
agenda
probably
at
our
next
meeting
and
give
you
an
opportunity
to
talk
about
that.
W
So
I
think
the
challenge
is
going
to
be
I.
Think
the
challenge
in
trying
to
say
we
need
a
formal
data
definition.
Language
to
use
is
finding
that
right
thing
to
do
like
I
said
neither
JCR
jason
schema
are
our
internet
standards
and
so
you're
going
to
have
to
cross
that
bridge
when
you
get
to
it.
So
I
think
the
the
the
first
question
ought
to
be.
Do
we
need
this
and
then
the
second
question
is
going
to
be
the
harder
one,
which
is
what
do
we
do
then
right
all
right.
Thank.
B
K
K
Chris
Froome
Corps
Association
I
want
to
bring
us
back
a
little
bit
again
into
the
beginning
and
into
their
fees.
Extension
and
I
have
a
general
comment,
which
I
think
was
more
appropriate
now
than
when
we
were
discussing
the
specifics,
and
that
is
I
have
noticed
that
many
of
the
registries
have
quite
a
few
differences
in
the
way
that
they
implement
the
fees
extension
and
especially
because,
of
course,
we
also
have
multiple
versions
of
it.
B
I'll
offer
two
comments.
You
know.
On
the
one
hand,
one
of
the
reasons
for
the
extension
is
because
there
are
different
implementations
of
the
way
people
do
it.
So
you
know-
and
those
of
us
who
are
here
or
trying
to
pay
attention
to
that,
and
that's
a
good
thing
and
the
other
thing
is
you're
right.
Currently
even
those
who
have
implemented
this
extension
because
it's
gone
through
a
couple
of
iterations.
B
You
know
protocol
adoption
in
generally,
ITF
I
can
make
the
standard
kind
of
response.
To
that.
You
know
people
do
things
because
they're
good
and
they
work
for
them
right.
There's,
there's
no
enforcement
mechanism
for
IETF
standards,
but
hopefully
we
have.
You
know
the
significant
people
here
and
people
will
see
the
value
and
they'll
want
to
adopt
it.
So
I,
you
know,
I,
don't
think
we
can
take
on
the
responsibility
of
promoting
adoption,
although
that's
kind
of
implicit
and
having
the
right
people
in
the
room
who
are
developing
the
standard,
but
they
may
change
so.
F
Do
yes,
Jim
go
from
Verisign
I
was
going
to
come
on
this
one,
the
night
a
separate
topic,
but
I
would
say
it's
better
to
have
these
graphs.
Otherwise
I
didn't
have
custom
extensions
that
the
Registry's
will
implement
in
five
different
ways.
So
that's
a
positive,
but
I
do
agree
with
you
that
there
are
complexities
with
the
registries
following
what
the
intent
of
the
graph
is
so
and
even
implementing
the
version
that
we
implemented,
which
was
the
O
six
prior
to
the
working
group.
Taking
it
we
had
saw.
F
L
K
E
E
For
some
time
I'm
sure
we
will
have
a
few
versions
that
we
run,
but
we
will
be
getting
rid
of
those,
so
we
will
be
suggesting
for
with
our
partners
to
move
forward
on
this
and
in
the
ICANN
world
there
is
a
tech,
ops
group,
that's
part
of
the
Registrar
stakeholders
group,
and
they
brought
this
topic
up
independent
a
month
or
so
ago
about
feet,
and
they
didn't
know
that
this
was
being
worked.
Some
of
them
did
not
know.
This
was
being
worked
here.
I
I
B
And
so
let
me
suggest,
if
you
wouldn't
mind,
you
know
explicitly
figure
that
out
and
and
send
a
note
to
the
mailing
list
and
make
it
visible
to
everyone
who's
on
the
list.
Whatever
constraints
are
there,
you
know
say
that
too,
but
I'll
point
it
out
of
subscribe
and
such
and
about
the
list.
Good
point:
okay,
new
topic
back.
F
To
Jamison
yeah,
this
was
brought
up
at
the
last
ITF
and
is
around
file
formats
specifically
around
the
data
escrow
address
that
are
out
there
that
are
being
implemented
by
a
lot
of
folks.
If
I
had
pretty
much
beat
this
group,
the
other
is
the
the
bulk
file
format
draft
that
I've
created
I
have
not
proposed
to
bring
that
forward
yet.
F
B
Well,
unfortunately,
part
of
what
happened
in
that
is
I
will
admit
to
having
dropped
the
ball
and
one
particular
key
issue.
Is
we
had
a
transition
of
area
directors
in
in
March
and
and
in
that
transition?
Although
I
had
on
my
list
of
things
to
talk
to
our
prior
Area
Director
about
it,
I
had
not
talked
to
our
new
Area
Director
about
the
fact
that
those
documents-
this
is
probably
the
best
place
for
those
documents
to
exist-
they're
not
really
strictly
EPP
or
or
our
Dapp.
B
So
you
know
we
need
to
have
that
negotiation
with
our
Area
Director
and
you
know
obviously
the
is.
She
has
to
weigh
in
on
whether
they
think
something
belongs
in
this
group
or
not
in
that
sense,
because
they're,
strictly
speaking,
a
little
out
of
scope,
but
on
the
other,
the
kind
of
in
scope
for
the
concept
of
what
we're
doing
here.
It.
F
B
F
B
B
But
under
the
assumption
that
so
I
either
either
will
move
forward
with
bringing
them
into
this
group,
which
will
then
bump
up
against
the
can't
do
anything
until
other
things
go
out
the
door
or
he
will
say
okay,
he
understands
he
wants
to
do
something
else
with
them.
Then
he'll
take
them
on
board,
but
I'll
have
that
discussion
with
him
and
then
we'll
send
a
note
to
the
list
and
let
everybody
know
what
that's
gonna
go
so
yeah.
Thank
you
for
that.
So
Annie.
W
What
he
his
his
document
and
I
read
it
it
talks
about
is
a
similar
problem
to,
but
we
commonly
see
as
bulk,
who
is-
and
there
are
formats
for
that
as
well,
which
kind
of
bumps
up
against
the
our
tap
stuff
right,
I.
Think
it's
a
slightly
different
problem,
but
I
think
this
is
the
place
to
make
sure
that
we
don't
complete
the
two
things
right
so
and.
B
And
you
know,
having
said
all
of
that,
and
is
our
area
director
is
actually
listening
here.
Anyone
else
want
to
comment
for
or
against
this
working
group
adopting
these
documents.
Hopefully
people
will
remember
the
document
since
we've
talked
about
them
in
the
past
and
and
I'm
not
seeing
a
lot
of
nodding
heads.
But
at
least
a
couple
of
the
principles
have
had
made
a
comment,
so
all
right,
so
all
right,
Adam,
you
want
to
come
in
our
esteemed
area,
director,
Adam
Roach,
no,
but.
Q
I
wanted
to
bring
up
was
I,
mean,
probably
a
two
powers
forward,
we'll
be
changing
the
Charter
and
putting
in
here
or
ad
sponsoring
it,
and
what
would
make
the
difference
between
those
two
is
really
how
many
working
group
participants
are
likely
to
actually
work
on
them.
If
we
can
get
broader
review
by
putting
it
in
here,
then
I
think
I'd
like
to
go
down
that
path.
Q
If
it's
just
really
going
to
be,
you
know
the
one
or
two
people
who
are
working
on
it
already,
we
probably
can
go
ahead
and
ad
sponsored
I
definitely
prefer
the
first.
If
we
could
get
enough
interest,
though
so
I
want
I
mean
people
just
want
to
like
raise
a
hand
and
say
yes,
we'll
work
on
this.
That
would
be
helpful
or
you
can
take
that
on
a
list
either
way,
but
that
would
be
a
useful
input
to
making
that
decision.
So.
B
B
F
I
clarify
the
request:
yes,
the
first
week
questions
whether
that
file
format
drafts
are
in
scope
for
this
working
group.
That's
number
one
and
then,
if
there
were
hum
it
would
be
under
the
data
escrow
drafts,
which
has
been
implemented.
I
have
many
many
folks,
I'm,
not
sure
about
in
this
room,
but
right.
B
There
are
a
couple
of
file
format,
documents,
there's
the
data
escrow
stuff
and
there's
the
pricing
stuff,
so
there's
actually
two
of
those
and
then
there's
a
separate
bulk
access
document
right
or
that's
what
you
meant
by
data
escrow.
That's
what
you
meant.
Oh
so
there
are
three
separate
things
to
worry
about
here:
yeah
yeah,
there.
F
Are
two
drafts
for
data
escrow
and
then
there's
one
for
bulk
file,
format,
okay
and
then
GoDaddy
had
another
one
for
pricey
yeah
for
the
file
formats
or
pricing
doc.
Is
there?
Is
there
another
one?
No
unavailable
me.
Okay,
this
way,
it's
it's
a
different
classification
of
work.
Yes,
so
when
that
that's
in
scope
or
not
yes,
thank.
O
X
Francisco
yeah
Francisco
is
I,
can
speaking
of
reviving
drops.
There
is
a
draft
on
the
team
series.
The
icon
teams
here
specification.
The
interface
was
originally
or
some
point
was
in
the
in
the
Charter
and
was
dropped
at
some
point
by
lack
of
priority
or
something
like
that.
I'm
actually
not
clear
on.
Why
was
drop
and
I
was
wondering
if
there
is
a
pat.
What
is
the
path
to
reviving
this
there?
X
B
Reason
why
that
document
was
dropped
was
because
the
idæan
matching
rules
were
unacceptable
and
they
there's
just
inconsistency
on
the
on
the
IQ
inside
about
that.
So,
from
my
point
of
view,
it's
it
was
Patrick
hallström.
You
know
Patrick,
okay,
who
is
the
principal
objector,
and
you
know
there
are
just
so
few
people
who
are
experts
on
that
space
and
dealing
with
this
issue.
B
If
you
go
back
and
you
look
in
the
archives
and
find
the
messages,
Patrick
was
very
clear
about
his
issues
and
until
those
issues
are
resolved,
you
know
we
really
can't
move
the
document
forward
and
I
realized
that
that
sounds
like
we
have
one
person
blocking
a
document,
but
you
know
they're
just
he's
an
expert.
If
anyone
else
wants
to
stand
up
and
be
one
you've
got
to
have
that
discussion
with
Patrick
and
resolve
it
so
Francisco.
X
S
X
B
Thank
you
for
that.
I
mean
I
can
only
say
that
from
from
my
point
of
view,
and-
and
you
know,
speaking
on
behalf
mantle
on
his
co-chairs,
I
mean
we
as
far
as
we
know
it
was
delegated
back
to
to
Patrick
and
it's
Gustavo
right
yeah
to
resolve
if
it
has
actually
been
resolved.
We
were
not
aware
of
that.
B
So
you
just
need
to
bring
that
information
forward
on
to
the
mailing
list,
and
then
then
we
can
take
it
from
there
and
and
of
course
now,
since
that
document
was
actually
dropped
off
our
milestone
list,
it
now
bumps
up
against
the
in
order
to
move
it
forward.
We
have
to
finish
what
we're
doing
and
then
we
get
to
add
it
back
in
and
make
it
happen.
Okay,
so
Thank.
X
B
I
mean
to
be
a
strict
point
of
process
thing:
I
guess
he
has
to.
He
has
to
send
in
a
revised
document
with
whatever
changes
came
out
of
that
and
I
guess
it's
still.
He
was
a
regex
working
I,
don't
think
it
was
left
as
an
individual
submission
right.
It
actually
had
been
been
renamed,
so
he
can
revise
the
document,
and
so
it
becomes
active
again.
But
they'll
have
to
ask
for
the
working
group
to
to
reconsider
the
issues.
B
B
B
B
T
B
Okay,
thank
you
for
that.
That's
a
that's
a
status
question,
but
we
can
yeah
we'll
need
to
keep
that
in
mind
too.
So,
did
you
get
that
Francisco?
If
you
want
to
comment
on
that
and
make
that
do
you
want
to
make
a
pitch
for
something
different
than
print?
Gustavo
will
need
to
say
that
too,
and
he
brings
the
document
back
up.
B
Okay,
any
other
business
questions
coming
from
anyone.
We
are
the
blue
sheets,
just
hold
them
up,
please
it
would
be
nice.
If
not
only
would
you
hold
them
up
so
I
can
see
them
if
you
could
bring
them
to
the
front
of
the
room
here
and
I
appreciate
that
and
I
guess
there
should
be
two
of
them.
I
only
see
one,
the
other
one
go.
Look
around
you
on
your
floor.
Folks,
somebody's
got
it
I,
don't
want
him
to
get
lost.
Oh
there,
we
go
all
right,
we
got
in
bolt.
So
alright,
that's
it!