►
From YouTube: IETF108-REGEXT-20200731-1100
Description
REGEXT meeting session at IETF108
2020/07/31 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
B
Okay,
let's
start
welcome
everybody.
This
is
the
registration
protocol,
extensions
working
group-
I
want
to
thank
you
all
for
being
here
morning
afternoon
evening
or
night,
and
a
special
welcome
to
all
the
sysadmins
in
our
group,
since
today
is
officially
international
system
administration
appreciation
day.
B
B
Did
you
have
a
next
slide
for
the
details
of
the
welcoming
introductions?
Jim,
I
think
you
did
yes.
So
for
the
jabra
scribe,
we
don't
have
a
jabra
scribe
yet,
but
I
will
be
watching
the
jabber
scribe
from
item
2
on
the
agenda.
So
don't
worry
about
that
and
we
have
a
minutes
taker
george,
who
is
doing
that
in
the
comet
thing
in
mid
echo.
So
if
anybody
wants
to
assist,
please
do.
B
Document
management:
we
will
have
an
oversight
later
on
in
the
meeting
and,
of
course,
all
the
time
we
have
special
attention
to
our
document
shepherds.
We're
very
pleased
that
since
we
introduced
pointing
or
asking
for
a
document
shepard
when
documents
are
adopted
in
our
working
group,
that
process
is
going
very
well
we're
very
content
with
it.
A
Okay,
so
we're
just
gonna
walk
through
our
documents
that
we
have
and
and
just
in
in
the
status
that
they're
in
on
on
the
page
and
the
folks
want
to
ask
any
questions.
That's
fine,
but
we
have
an
awful
lot
of
documents
that
are
kind
of
in
progress
along
the
way
towards
publication.
A
Unfortunately,
this
meeting,
we
don't
have
any
documents
that
have
been
published
since
the
last
meeting.
We've
actually
been
pretty
good
lately
and
having
won
the
last
couple
of
meetings,
but
not
this
time.
On
the
other
hand,
we
have
quite
a
few
documents
that
are
getting
very
close
to
being
published.
The
login
security
sanctions
is
in
the
rfc
editor
queue.
A
We
have
the
data
escrow
documents
or
an
iesg
evaluation.
We've
been
going
through
some
comments
there,
just
coding
off
on
some
comments
from
some
of
the
isg
members,
but
I
do
think
they're
in
a
good
place
and
getting
ready
to
be
handed
off
to
the
rfc
editor.
A
Soon
we
have
the
functional
spec
specification,
something
which
was
kind
of
languishing
for
for
years,
while
we
waited
for
some
icann
processes
to
catch
up
and
now
they're
in
a
place
where
they'll
be
under
review
here
with
our
area
director
and
barry,
I
see
you
out
there
in
the
queue,
so
please
go
ahead.
C
The
so
for
this
document,
I'm
actually
suggesting
that
we
move
this.
We
take
this
out
of
the
working
group
and
move
it
to
the
independent
stream,
and
I
I
haven't.
I
I
owe
a
reply
on
this.
The
issue
isn't
that
it's
informational,
that
it's
perfectly
fine,
of
course,
for
the
working
group
to
informational
documents.
C
It's
just
that
this
particular
document
is
more
documenting
an
I
can
process,
and
what
would
it
really
mean
to
say
that
the
ietf
has
consensus
on
document?
It's
not
something
that
we
can
really
change,
because
it's
documenting
something
from
icann.
C
A
D
Gustavo,
that's
one
question
for
the
independent
submission,
the
stream.
I
it
may
understand
that
you
need
to
have
the
one
of
the
other
directors
to
sponsor
your
your
draft
or
something
like
that.
Is
that
correct.
C
The
independent
stream
you
contact
the
rfc
editor
directly
adrian
farrell
is
the
independent
stream
editor
and
he
will
go
through
a
lightweight
review
process
with
you
and
publish
the
document
directly
and
it
does
not
go
through
ietf
consensus.
It's
just
it's
just
published.
D
Okay
got
it
so
I
I
don't
know
you
should
we
discuss
in
the
mailing
list
if
this
is
the
way
to
go,
or
do
you
want
to
discuss
it
here
I
mean
I
I
don't
know
what
is
the
next.
A
Step
we
can
certainly
ask
the
question
here
if
anyone
else
would
like
to
comment
and
has
anything
you
want
to
say,
but
I
suspect
we
should
just
make
sure
there's
no
objections
on
the
mailing
list.
If
anyone
wants
to
make
a
case
a
in
a
different
direction,
barry's
making
a
suggestion
about
what
to
do
with
it.
Unless
someone
has
a
strong
opinion
about
something
different,
then
I
would
guess
that
that's
the
direction
you'll
go
in,
but
rich.
I
see
you
in
the
queue.
If
you
go
ahead,
please.
E
Hear
me:
okay,
yeah
loud
and
clear
thanks.
This
is
this
is
a
a
gentle
comment.
I
certainly
agree
with
and
and
understand,
where
barry
is
coming
from
and
understanding
his
position
and
point
about
the.
Where
he's
saying
about
a
working
group
document.
One
of
the
reasons
that
that
I
can
is
in
the
I
can
process
is
is
leveraging
the
the
work
of
the
ietf
in
this
situation
and
in
similar
situations,
is
in
order
to
actually
get
the
the
input
and
the
input
and
and
wisdom.
E
I
guess
for
lack
of
a
better
term
of
the
technical
community
on
on
these
kinds
of
of
things,
and
so,
while
it
it
barry's
points,
have
a
ton
of
merit.
One
of
the
concerns
with
moving
it
to
the
independent
stream
would
be.
How
do
these
kinds
of
documents
get
the
kind
of
broad
technical
input
and
review
from
the
the
community
of
technical
experts
that
exists
in
regex
in
order
to
drive
the
kind
of
technical
quality
into
the
into
a
functional
specification
like
this,
as
it
got
via
the
thorough
working
group
review
here?
E
C
So
richard
that
exactly
I
I
agree
with
you
and
I
think
it's
perfectly
fine
for
the
and
the
working
group
has
worked
on
this
document
and
has
finished
because
it
was
sent
up
to
me.
C
I
think
it's
perfectly
fine
for
the
working
group
to
process
one
of
these
documents.
A
document
like
this
provide
its
technical
input
have
the
conversations,
but
then,
in
the
end,
say
this.
The
publication
of
this
document
really
belongs
with
the
independent
stream,
not
with
the
ietf
stream,
because
you,
the
working
group,
has
given
its
input,
but
coming
in
saying
that
this
document
is
an
ietf
consensus.
Document
is
kind
of
funny
in
this
case,
so
yeah.
I
think
this.
E
Okay,
that,
that's
that's
a
great
clarification
barry.
Thank
you
very
much
and
this
roger
said
plus
one
there.
Thank
you.
A
Okay,
that
sounds
good.
I
think
what
that
turns
into
gustavo
is
we
probably
should,
because
not
everyone
attends
this
audio
meeting
and
in
in
principle,
you
know
it
is
the
mailing
list
in
which
we
conduct
our
work.
It
would
be
helpful
to
probably
ask
the
question
on
the
mailing
list
and
just
make
sure
that
no
one
objects
and
then
pull
it
out.
I
mean
if
you're
looking
for
working
group
review.
I
think
that
would
be
a
you
know.
C
C
A
Thanks
and
it
looked
like
somebody
popped
in
and
out
of
the
queue
there,
I
think
that
was
joseph.
Did
you
want
to
talk
joseph
give
you
another
minute
to
get
back
in
the
queue.
A
A
Well,
I'm
glad
we
got
that
out
of
the
way
and
settled
so
thanks
for
that,
okay,
so
going
through
the
rest
of
the
documents
here,
we
just
recently
put
in
just
a
few
weeks
ago,
the
rdap
partial
response
and
the
sorting
and
paging
documents
we've
been
progressing,
those
along
for
a
while,
so
that's
out
there
and
I
believe,
barry's
getting
ready.
C
To
call
now.
A
Okay,
yes,
they're
on
the
agenda
and
going
through
reviews.
So
thank
you
for
that
barry
and
we
have
so
that
takes
care
of
existing
work
documents
that
are
in
the
publication
cycle
at
some
point
along
in
the
process.
A
There's
one
other
document
I'm
going
to
mention
in
this
section,
which
is
actually
a
working
group
document,
and
it
has
been
for
a
while.
We
remind
ourselves
of
each
meeting.
This
document
is,
is
paused
at
the
moment.
It's
actively
will
be
actively
considered
when
there's
an.
A
Group,
which
is
getting
ready
now,
hopefully
soon
to
begin
doing
some
work
with
respect
to
authenticated
queries,
and
so
there
will
be
some
interoperability
testing
and
lots
of
implementation
of
this,
and
perhaps
some
other
things,
but
in
any
case
this
work
will
become
active
as
soon
as
there's
some
active
development
going
on
so
we're
just
holding
the
document
at
the
moment.
It's
just
sitting
on
pause
in
our
working
group
waiting
for
that
and
that
takes
us
into
a
quick
milestone
review
for
status
of
our
current
work.
A
This
represents
the
list
of
documents
that
actually
do
belong
to
this
working
group,
you'll
notice,
at
the
top
that
we
have
one
document
which
currently
has
a
past
due
milestone,
review,
I'm
not
going
to
focus
too
much
on
these
right
now.
Each
of
these
documents
is
going
to
get
a
little
bit
of
time
shortly
in
the
next
section,
we're
going
to
walk
through
all
of
our
open
documents.
A
Here
I
will,
I
point
out
the
past:
do
one
at
the
top
and
then
on
march,
21st
you'll
notice
that
march
2021,
rather
not
21st,
21
next
year,
the
open
id
document
we
were
just
talking
about.
We
pushed
out
the
milestone
to
next
year
in
in
hopes
of
that
work
actually
beginning
this
year.
A
We're
still
hopeful
about
that,
and
you
know
we'll
and,
and
that
way
we'll
hopefully
try
to
get
this
document
wrapped
up
and
ready
to
go,
and
then
we're
gonna
see
in
the
conversation
that
we
are
about
to
have.
We
have
a
number
of
documents
that
don't
have
a
milestone
date,
yet
so
as
part
of
the
discussion
that
we're
about
to
get
into
we're
going
to
review
all
of
these
documents.
A
These
working
group
documents
that
are
just
sitting
here
and
we'll
be
asking
about
milestones
that
we
don't
have
and
document
shepherds
and
such
as
we
need
them.
So
I
think
with
that
we
will
move
into
the
next
area
of
our
agenda,
which
is
calling
existing
work,
which
is
now
going
through
all
of
our
documents
and
antoine.
I
think
back
over
to
you
right.
B
I
I
I
can
do
this,
but
I
was
I
was.
I
was
watching
the
the
the
jabber
and
the
cube
anyway.
Existing
work
reverse
search
capabilities.
Yes,
that's
a
a
good
document
I
think
to
discuss.
I
don't
know
if,
let's
see,
if
mario
is
here,
the
reverse
search
is
actually
you
know,
we
know
what
we
need
to
do
with
this
document.
B
There
were
some
comments,
then,
when
we
discuss
this
document
about
the
human
from
the
human
rights
group-
and
we
wanted
to
have
some
input
in
there-
some
text
in
there
about
that
and
we're
still
waiting
for
that.
So
my
question
to
the
working
group
is:
what
do
we
do
with
it?
Do
we
just
put
it
on
the
mailing
list
and
say
you
know
nobody
is
commenting,
but
everybody's
objecting.
B
What
would
be
the
suggestion
of
the
birken
group?
Is
there
anybody
that
wants
to
comment.
B
Because
if
you
don't
get
any
advice
or
feedback
from
the
from
the
working
group,
we
will
consider
this
document
as
not
being
wanted.
I
don't
think
that's
something
that
some
people
in
this
work
might
want
to
want.
A
Yeah,
if
I
can
just
you
know,
add
to
that
a
little
bit
while
we're
waiting
for
for
someone
to
jump
up.
Part
of
this
discussion
that
we
want
to
have
about
our
existing
documents
here
is:
are
we
going
to
proceed
with
these
documents
and
are
we
going
to
work
on
them?
Searching
is
the
you
know?
Third
of
the
there
was
sort
of
that
set
of
rdap
documents,
sorting
in
paging
and
partial
response
and
searching
was
there
and
it's
kind
of
the
last
one
in
the
in
the
group.
A
But
there
is
just
a
question
to
this
group
at
all,
are
are
we
going
to
deal
with
the
searching
issue
in
in
our
dap?
Are
we
looking
to
do
any
work
in
this
space?
I
mean
it's
fair
to
say
that
we're
not
or
we
need
someone
to
step
up
and
say
they
want
to
move
forward
with
it
and
and
resolve
the
question
of
what
features
and
services
we
need,
and
now
we
can
stop
talking,
because
we
have
george
in
the
queue
so
george
go
ahead.
G
It
may
not
be
a
charter
goal,
but
it's
most
definitely
a
goal
in
our
heads
we
have,
who
is
it
sucks?
Our
daf
is
better.
We
want
our
dap
to
be
fully
capable
because
we
are
considering
a
future
world
where
we
deprecate,
who
is,
or
we
call
rdap
who
is
so
who
is
in
number
space,
has
support
for
reverse
search
mechanisms.
G
Now
I
understand
that
there
are
significant
privacy
risks
and
concerns,
and
I
understand
why
the
community
would
say
be
very
careful,
but
the
idea
of
saying
oh,
we
don't
want
to
do
this.
That
really
doesn't
fly
with
me,
because
this
is
a
fundamental
tool
used
by
law
enforcement
and
related
agencies
performing
searches
in
our
who
is
so,
if
we're
going
to
call
rdap
a
functional
replacement
for
who
is,
it
has
to
support
this
kind
of
technology
or
it
has
to
have
a
body
of
work.
That
explains
why
not.
F
See-
and
I
just
wanted
to
say
that
the
reverse
search
I
mean
we
have
had
this
document
coming
up
in
our
meetings
sometimes,
and
we
always
have
this
problem
with
the
security
and
the
privacy
considerations,
and
I
mean-
and
I
think
that
is
the
main
problem
with
the
document.
F
I
think
we
have
actually
agreement
in
the
group
or
I
had
the
feeling
that
we
had
an
agreement
in
the
group
that
the
functionality
is
very
much
needed,
but
the
privacy
part
can't
just
say
follow
the
law.
It
has
to
say
something
more,
and
I
think
that
is
the
fundamental
problem
with
the
document.
F
As
I
said,
I
think
the
functionality
is
very
much
needed,
and
so
I
think
we,
but
if
I
can,
is
going
to
have
and
a
big
working
group
around
this.
Maybe
this
is
something
that
even
should
be
tested
in
that
working
group
and
that
we
should
revisit
this
document
after
the
this
networking
group
has
come
to
a
conclusion:
how
to
do
that
and
what
the
privacy
was
about.
A
Thank
you
so
before
we
before
we
go
to
gym,
I
want
to
just
respond
to
one
thing
that
that
ulrich
said
you
know,
at
least
from
my
point
of
view.
You
said,
shares
prerogative
here
and
jump
in
you're
talking
about
icann
having
its
own
working
group.
I
think
that
icann
has
some
policy
considerations
with
respect
to
searching,
but
it
needs
this
technical
specification
in
order
to
properly
you
know,
propose
and
manage
its
policy
considerations,
and-
and
I
think
that
that
folks
are
right.
A
Listening
to
george
and
and
listening
to
to
ulrich
here,
we
most
of
the
discussion
that
we've
had
in
our
mailing
list
has
been
about
the
privacy
and
security
considerations,
and
there
there's
been
a
small
group
of
people
who
have
been
really
just
objecting
to
this
document,
suggesting
that
we're
not
addressing
those
concerns.
A
I
don't
know
what
exactly
the
right
way
is
to
deal
with,
that
we've
asked
them
for
text
and
they
don't.
You
know
they
provided
some
rather
lengthy
and
extensive
text,
which
seemed
inappropriate
also,
so
we're
gonna
have
to
find
a
way
to
get
past.
That
question
is,
is
the
technical
specification
enough?
Is
it
done
in
its
own
face
and
then
we've
got
to
find
a
way
to
get
past
the
privacy
and
security
considerations
so
that
we
can
move
on
with
this
document
and
make
it
available
and
I'll
be
quiet?
A
Now,
let's
get
to
some
working
group
members
here,
I
guess
jim
reed
is
next.
Yes,.
I
Thanks
tim,
I
was
going
to
do
a
rant
about
who
is
an
adapt,
but
I
thought
better
about
it.
I
always
suggest
what
we
try
to
do
here
is
just
focus
exclusively
on
the
technical
concerns
and
when
it
comes
to
the
in
problems
around
privacy,
security
and
all
the
other
achy
nasty
stuff
that
surrounds
this
whole
adapt
who
is
space,
I
think
all
we
can
really
see
here
is
that
this
problem
is
intractable,
intractable
from
a
technical
point
of
view,
there's
no
way
that
the
itf
or
anybody
else
can
solve
that
problem.
I
Don't
even
try
and
it's
up
to
individual
registries
when
they
implement
this
protocol
to
take
their
own
local
legal
advice
about
what
they
have
to
do
about
this,
because
that
will
be
different.
I
know
that,
for
example,
that
everyone
starts
talking
about
gdpr
gdpr
is
all
over
the
place,
but
even
within
the
countries
that
are
bound
by
gdpr.
I
I
So
don't
even
attempt
to
try
and
solve
this
problem,
because
it's
completely
and
utterly
broken
and
can't
be
fixed,
and
the
best
that
can
be
done
is
to
say
to
somebody
that's
going
to
stand
up
an
adapt
server
for
whatever
purpose
it
is
consult
your
local
lawyers
and
local
law
enforcement
and
government.
That's
the
only
thing
we
can
do
here.
B
A
B
A
Okay,
roger
dropped
out,
let's
move
to
yazda
and
he
has
dropped
out
also.
A
Buttons,
hey,
okay,
roger
hold
on
a
second,
let's
just
let's
say
yes
to
roger,
and
now
you
should
be
able
to
talk
roger.
A
Anyway,
yeah
you
need
to
wait,
you
just
need
to
wait
to
be
approved
and,
and
it
works,
there's
also.
The
the
immediate
send
button
is
a
is
a
different
thing.
There's
the
two
microphones,
if
you,
if
you
hit
the
send
audio,
then
it
just
blasts
into
the
room
while
you're
talking.
J
Okay,
great
getting
back
to
the
question
it
seems
like
this
is
something
then
someone
from
the
number
side
should
try
to
push
the
pin
with
then.
If
the
name
side
does
not
have
an
interest
in
this,
then
someone
on
the
number
side
should
probably
pick
up
the
pin
and
run,
and
everybody
here
obviously
can
contribute,
but
it
seems
like
if
we're
looking
for
someone
to
do
this,
someone
from
the
number
side
should
step
up
since
it's
a
fundamental
issue
for
them.
Thanks.
A
A
Just
just
put
your
hand
up
just
put
your
hand
up
put
the
hand
up
on
the
microphone
and
then
wait.
Okay
and
now
just
start
talking.
J
H
Yes,
so
so
mike,
my
question
was
that
basically,
this
seemed
to
be
a
problem
just
just
with
the
numbers,
as
roger
said
since,
when,
when
someone
goes
in
to
put
anything
into,
I
believe
it's
apnic
or
anything
else,
they're,
basically
giving
up
their
privacy
so
that
their
information
can
be
searched
on
the
internet
like
that,
it's
not
the
same
way
for
domain
registrars
or
registries.
H
So
there
are
two
fundamentally
different
implementations
as
far
as
privacy
is
concerned
in
it
for
the
the
regional
mix,
when
someone
applies
for
a
number
or
or
or
for
an
ip,
they
give
up
their
they
give
up
their
privacy.
Basically,
because
that's
part
of
signing
up
is
that
your
name
will
be
searched
on
the
internet
and
it
will
be
displayed,
but
that's
not
the
same
for
domains
or
for
what
icann
is
concerned.
So
I
agree
with
roger
that.
That's
that's
why
it's
got
to
be
too
different.
H
A
Okay,
thanks,
let's
put
a
lo,
fill
out
the
cue
here.
I
have
a
point
of
view
too,
but
I
want
to
finish
to
rolling
out
the
cue
here
and
then
we
got
to
move
on
to
one
of
the
other
documents.
I
think
we're
only
planning
to
have
about
10
minutes
of
document.
We
can
come
back
to
this
later
scott.
You
should
be
able
to
speak
now.
K
Thanks
jim,
this
is
scott
hollenbeck,
so
I
just
I
noticed
two
things
while
looking
at
the
draft
just
now,
it
does
have
privacy
and
security
considerations
sections
and
if
we
think
that
the
text
that's
there
is
inadequate,
I
mean
we
should
certainly
propose
whatever
kinds
of
changes
are
necessary
to
address
the
types
of
concerns
we're
talking
about
right
now.
Secondly,
it
does
note
that
there
are
no
ionic
considerations.
That's
probably
incorrect,
like
any
rdap
extension,
there
should
probably
be
something
registered
there.
K
You
know
that
would
appear
in
the
rdap
conformance
section
of
a
response
to
note
that
you
know
hey
I'm
doing
something
beyond
the
course
facts,
so
my
I
don't
know
is
mario
on
the
call.
K
Anyway,
okay
I'll
be
back
to
the
list.
A
Thanks
scott,
okay
jess:
if
we're
going
to
just
approve
your
microphone
and
then
you
should
be
able
to
just
talk,
don't
do
anything
as
soon
as
you
approve
it
breaks
up
yeah.
I
think
you're
hitting
the
microphone
button
again
and
that
takes
it
away.
You
don't
have
to
press
the
button
to
talk.
You
just
have
to
press
to
ask
permission
and
then
we
push
we
press
the
button
for
the
microphone
yeah.
A
Nope,
no
okay,
my
you
know
speaking
as
chair.
I
I
think
the
problem
with
with
this
document
has
been
that
we
never
got
past
the
privacy
and
security
considerations
discussion
here,
thanks
scott
for
noticing
the
ayanna
question
too.
That
actually
is
a
technical
issue
that
we
do
need
to
deal
with
in
the
document,
but.
F
A
Kind
of
felt
that
we
just
never
really
seemed
to
quite
get
consensus
on
what
to
put
in
privacy
and
security
considerations.
I
the
proposal
that
I
would
have
here
that
we've
never
really
gotten
text.
For,
unfortunately,
is
I
don't
think
we
necessarily
have
to
solve
the
problem
of
privacy
and
security.
We
simply
have
to
call
it
out
and
observe
the
issues
and
concerns,
and
I
think
jim
reed,
probably
characterized
it
best
when
he
simply
said
you
know,
one
of
the
problems
with
with
privacy
and
the
functionality
is.
A
A
We
need
to
call
that
out
as
a
concern
and
leave
that,
but
we
never
seem
to
get
consensus
in
the
working
group
on
that
issue,
so
maybe
for
right
now
the
answer
is,
you
know:
do
we
want
to
to
move
this
document
along
and
if
so,
we
have
to
find
a
way
on
the
mailing
list
to
come
to
closure
on
on
the
text
that
needs
to
go
in
that
section,
I
think,
from
a
technical
point
of
view,
we
really
haven't
had
any
issues
with
this
document.
A
You
know
for
a
long
time,
except
for
scott,
pointing
out
the
iana
issue
that
we
do
need
to
to
fix.
So
for
this
document
we
do
need.
I
I
meant
to
check
again
here
real
quick,
because
I
don't
actually
remember
if
this
document
needs
a
document
shepard.
A
I
believe
that
it
does
most
of
our
documents
here,
so
we're
going
to
need
a
document
for
this
document
as
well
as
we're
going
to
need
an
updated
milestone,
and
so
that's
really
what
we're
looking
for
in
all
of
these
documents
as
a
shepherd
and
a
milestone.
If
we're
going
to
move
that
work
along,
it
sounds
like
there's.
Some
some
desire
need
to
move
this
along,
so
we'll
have
to
take
that
to
the
mailing
list
and
and
see
if
we
can't
force
that
to
happen.
B
B
K
Sure,
thanks
antoine
scott
holland
back
here,
I
think
these
two
documents
are
ready
for
working
group
last
call
when
they
were
individual
submissions.
We
spent
quite
a
bit
of
time.
You
know
looking
at
the
various
you
know
the
errata,
the
corrections,
the
clarifications
that
were
necessary.
They
were
all
taken
care
of.
We
do
have
document
shepherds
identified
for
both
all
of
the
document.
Shepard
review
comments
have
been
addressed,
the
documents
that
have
been
out
there
with
the
request
for
feedback
we
haven't
gotten
any
now
for
a
little
while.
K
So
given
that
I
said,
I
think
these
are
ready
for
working
group.
Last
call.
A
Both
documents
have
a
document
shepard.
The
query
document
is
with
mario
and
the
response
document
is
with
jazz
it,
so
both
are
ready
to
go
as
far
as
that's
concerned.
Just
a
quick
question
to
scott.
I
never
actually
I
don't
recall
making
this
distinction
in
those
who
commented
on
the
documents.
Would
you
say,
we've
gotten
it
it's
clear
from
your
point
of
view
that
both
numbers
and
names
community
have
looked
at
this
document.
K
Thanks,
jim
yeah,
scott
hollenbeck
again,
yes,
if
you
look
at
the
feedback,
that's
on
the
mailing
list.
I
know
I've
gotten.
You
know
quite
a
bit
of
feedback
from
jazz
deep
in
particular.
Now
I
mean
jasmine,
not
the
whole
numbers
community,
but
he's.
Certainly
a
representative
and
and
mario
lafredo
has
also
been
you
know,
very
prolific
in
terms
of
providing
feedback.
K
So-
and
I
know
this
has
also
been
looked
at
pretty
extensively
in
what
we
did
with
the
icann
community.
You
know
around
the
operational
profile
that
they
did
for
our
dap.
You
know
quite
a
bit
of
that
found
its
way
into
the
necessary
clarifications
and
corrections.
B
B
M
Fantastic
yeah,
so
the
last
update
on
this
draft
was
done
prior
to
the
interior
meeting,
where
we
added
signaling
for
the
client
and
the
server
and
log
in
and
the
greeting
services,
and
we
also
added
a
registration
in
the
iana
consideration
section.
We
have
identified
a
is
this,
which
is
this:
the
unhandled,
I'm
sorry
or
the
secure
off
info.
M
I'm
sorry
I
was
doing
the
opposite,
we'll
just
cover
the
unhandled
first.
How
about
that?
Okay,
sorry
about
that
yeah
yeah.
We
did
identify
a
document
shepard
with
david
smith
and
all
all
the
review
feedback
has
been
addressed,
but
pretty
much
the
only
work
remaining.
I
think
on
this,
and
the
other
draft
is
to
talk
about
the
track
of
the
drafts,
I
think
other
than
the
the
track.
M
I
believe
they're
both
ready
for
working
group
last
call
so
I'd
like
to
have
a
more
detailed
discussion
around
the
use
of
the
bcp
track
for
both
these
documents,
but
other
than
that
they
would
be
good
to
go.
M
So
that's
the
that's
the
unhandled
namespaces
draft
on
the
secure
auth
info
for
transfer.
Again,
we
added
the
signaling
for
the
client
and
server
in
the
login
greetings
services.
There
are
updates
made
to
the
draft
associated
with
inclusion
of
the
random
salt
in
the
hash
auth
info.
M
We
added
clarification
to
representation
of
the
null
value
being
dependent
on
the
database
and
we
added
in
the
security
consideration
section
so
with
this
jody
coker
is
the
document
shepard
already
and
again
the
work
is
done.
I
believe
on
these
graphs.
The
only
thing
remaining
to
discuss
is
the
the
track.
M
The
only
thing
we've
discussed
is
multiple
times
is
the
track
and
barry
had
pointed
out
section
three
of
roc
2026,
which
in
looking
at
that,
I
wasn't
sure
maybe
barry
can
speak
to
this
was
whether
or
not
he
was
suggesting
use
of
the
applicability
statement
standards
track
for
these
drafts.
M
So
you
have
the
technical
spec.
You
also
have
the
applicability
statement
for
being
standards
track,
and
then
we
have
the
bcp
I
feel
like
they
are
bcp,
because
they're
really
not
defining
protocol
the
defining
practices
to
increase
the
security
or
the
compliance
of
implementations
of
the
existing
rfcs.
M
C
Microphone
to
kill
the
echo
okay,
the
it
it
was
just
a
suggestion
of
something
you
might
consider,
not
saying
that
that
I
thought
you
should
that
that
should
be
what
the
working
group
should
do.
The
working
group
should
consider
the
possibility,
an
applicability
statement.
A
technical
specification
specifies
protocol,
an
applicability
statement.
Excuse
me
does
not
necessarily
specify
protocol.
It
specifies
how
to
use
the
protocol,
in
particular
situations.
C
What
you
described
fits
very
well
with
that,
but
you
know
arguably
so
does
bcp,
and
it's
just
a
question
of
whether
you
think
that
this
is
a
standard
for
how
to
use
the
protocol
or
whether
you're
just
saying
that
this
is
the
current
practice
and
that
that
might
change
and
there
might
be
a
a
different
current
practice
at
a
different
time
and
whether
the
whether
you
want
to
call
it
a
standard
or
not.
C
So
it
it's
it's
up
to
the
judgment
of
the
working
group,
but
I'm
happy
to
go
with
whichever
you
think,
but
I
think
applicability
statement
is
what
you.
What
you
described
is
that
what
you
described
sounds
like
applicability
statement
to.
C
M
Yeah
so,
and
when
I
read
through
2026
on
the
applicability
statement,
it
says
it's
how
and
under
what
circumstances,
one
or
more
technical
suspects
may
be
applied
to
support
a
particular
internet
capability
yeah.
I
think
I
think
it
could
fit
in
that
and
although
I
was
looking
at
the
bcp
and
it's
discussing,
you
know
designed
to
be
a
way
to
standardize
practices.
M
So
it's
is
that
super
clear.
It
falls
into
any
one
of
these,
but
I
I
guess
I
still
feel
that
the
bcp
is
the
right
track
for
these,
and
I
like
to
hear
from
others
on
the
the
working.
B
B
When
I
look
at
the
data
tracker,
I
do
see
that
the
unhandled
namespaces
has
no
document
shepard
assigned
yet.
Did
you
discuss
that
with
us
on
the
mailing
list?
I
forgot
yes,
go
ahead.
M
Yeah
no,
I
did.
I
sent
a
message
saying
that
I
identified
david
smith
from
verisign
to
be
the
doctor.
B
B
C
M
A
We'll
include
the
question
of
the
status
you
know
is,
as
part
of
the
last
call
just
a
reminder
to
folks
of
the
status
of
the
documents
and
we'll
we'll
see
what
comes
of
that
also.
But
you
know
thanks
jim
for
that,
and
I
don't
even
know
that
I
have
a
strong
opinion.
Quite
honestly.
So
probably
if
you're
happy
and
no
one
objects,
then
that's
the
direction
we'll
go
in.
A
Okay,
actually,
no,
that
brings
us
to
the
end
of
our
existing
work
and
I
think
that
we,
the
only
thing
we
didn't
do-
was
a
new
milestone
for
reverse
search,
but
that
there's
some
work
to
be
done
there.
So
we
can
take
that
to
the
whaling
list,
but
I
think
we're
all
pretty
well
set
on
everything
else.
So
we'll
just
clean
up
our
administrative
tasks
here
and
we'll
be
ready
to
go.
A
We
only
have
one
other
significant
work
item
on
our
list
and
that's
the
next
slide
here
is
the
one
other
working
group
document
that
we
have
and
we
have
a
presentation
for
that
document.
So,
if
you're
ready
antoine,
we
can,
we
can
move
to
that.
B
B
N
Hello,
hello,
joseph
we
hear
you
hi
anton
thanks.
I
was
like
I
was
concerned
about
the
microphone
thanks.
Everyone.
So
do
I
control
this
line,
so
I
have
to
ask
you
to
to
to
turn
the
page.
N
A
A
I
suppose
you
should
probably
maybe
I'll
take
a
moment
to
say
and
just
just
remind
people.
I've
said
this
before,
but
I'll
say
it
again.
You
know,
since
you
know,
I
am
co-chair
here
with
antoine,
but
joseph
and
I
are
doing
this
document
together,
I'm
I'm
going
to
refuse
from
any
chair
responsibilities
with
respect
to
handling
of
this
document
so
that
it
will
just
be
on
antoine
so
that
we
don't
have
any
any
issues
there.
That's
that's
my
intent.
A
N
A
B
Jim
you
put
on
the
note
well
message:
you
yeah
switched
over
from
presentation:
no
okay,
there.
It
is
so
go
ahead.
Joseph.
N
Just
brief
history,
I
was
adopted
by
the
working
group
in
may
2020.
The
the
initial
versions
was
published
on
june
1st,
the
the
most
recent
versions,
vision,
01,
was
published
on
july
13th.
N
Currently
working
progress
is
expanding.
The
test
on
on
setting
up
the
ini
registry
for
the
fusion
report,
and
so
far
right
now
we
have
defined
34
fields
and
seven
reports
next
slide
report
specifications
as
sessions
we
have
reference
rfc
4180
for
the
csv
specifications
and
the
first
line
of
the
report
is
always
the
column
headings,
which
is
the
the
field
values.
The
view
names
that
we
intend
to
be
registered
with
the
anna.
N
So
far,
we
have
some
open
questions
that
needs
to
get
more
more
while
broadly
discussed.
One
of
the
question
is:
can
the
view
be
allowed?
Being
optional
means
that
if
does
registry
operator
allows
to
not
report
anything
about
a
particular
column?
And
if
we
do
not,
if
we
do
not
reporting
any,
what
would
the
value
of
that
not
not
reported
columns
b?
Would
it
be
n,
slash,
j,
blank,
zero
or
anything.
N
Can
the
column
additional
column
headings
may?
Can
it
be
ignored
and
also
unrecognized
columns
cells?
The
difference
between
the
additional
columns
and
then
and
you
recognize
columns
is
unrecognized.
Columns
is
the
one
that
is
not
registered
in
the
ini
registry
next
slide
in
the
draft
01,
the
most
recent
one
I
actually
put
on
one
extra
column
too,
just
to
help
visualize
on
that.
So
that
is
not
the.
N
The
prop
is
not
standard
on
top
yet,
but
I'm
just
adding
the
extra
column
here
to
help
further
the
discussions
that's
only
available
in
session
3.1
of
the
transaction
report.
N
A
So
you're
very
choppy,
there's
a
lot
of
comments.
There's
quite
a
few
comments
in
the
chat
room
here
about
this.
You
really
do
seem
to
be
going
in
and
out
are
you
still
on
the
report
specification.
A
I
think
maybe
maybe
we
should
we
should
trade
off
here
and
because
it's
just
too
choppy
coming
from
you,
you
just
you're,
dropping
it
dropping
too
much.
Okay,
okay,
so
report
specifications.
Let
me
just
just
touch
quickly.
Those
open
questions
at
the
bottom
are,
just
you
know,
work
in
progress
as
joseph
was
was
saying
and
their
questions
to
the
group
here.
So
we'll
have
more
discussion
about
that
on
the
sides.
A
We
were
having
a
discussion
and
a
question
about
whether
individual
fields
were
mandatory
or
optional
in
in
terms
of
when
they
would
appear
in
a
particular
standard
report,
and
so
this
is
really
a
question
for
folks
to
consider
you
know
in
in
the
standard
reports.
What
happens
you
know?
Does
there
always
have
to
be
a
value?
There
are
all
fields
always
required
when
they're
defined
for
the
report,
and
so
this
is
just
one
example
in
a
transaction
report.
A
You
know
we
kind
of
make
a
suggestion
here
about
whether
the
value
should
be
present
or
not.
I
think
there's
just
a
larger
question
in
general
about
the
mandatory
versus
optional
on
fields
in
reports
in
columns
and
reports.
I
think
that
we
just
have
to
make
a
choice
about
how
we
want
to
process
them.
A
There's,
certainly
an
argument
in
favor
of
both
you
know.
Maybe
the
field
is
present.
Maybe
it's
not
if
it
is,
there
should
be
a
value,
and
if
it's
not
present,
that's
okay,
too
you'll
figure
that
out
and
looking
at
column
at
row,
one
in
the
file
because
you'll
know
which
columns
are
present
and
where
they
are.
So
we
just
want
to
call
that
out
as
a
decision
that
a
choice
that
we
need
to
make
about
how
folks
want
to
process
it.
A
There
are
just
the
question
of
whether
or
not
the
reports
that
are
currently
defined
you
know
do
we
have
all
the
column
headings
that
we
want
to
have
in
those
reports,
so
we
need
some
consideration.
We
need
broader
review
by
more
registry
operators.
We'd
like
people
to
look
at
that.
Also
more
registrars,
you
know,
creating
a
standard
set
of
reports
is
sort
of
an
interesting
proposal.
A
There's
there's
plenty
of
room
for
you,
know
ad
hoc
reports
and
plenty
of
room,
for
you
know
less
universally
available
reports,
but
do
we
have
the
right
set
of
minimum
reports
and
and
of
course,
the
columns
that
need
to
be
in
them,
and
we
really
would
would
like
some
consideration
about
that.
We
captured
what
we
know,
but
you
know
broader
review
is
sure
to
identify
some
things
that
are
missing.
A
Are
there
any
other
reports
that
we
haven't
captured
recall
that
this
document
was
originally
drawn
from
the
best
practices
website
there
were.
You
know
nine
report
specifications
that
were
detailed
there.
We've
captured
all
of
that
here,
but
certainly
there's
an
opportunity
for
us
to
think
about
whether
or
not
there
are
other
reports
we
want
to
define,
as
part
of
you
know,
creating
this
mechanism
for
managing
the
presence
of
reports.
A
And
finally,
you
know,
even
if
we
don't
define
reports
in
this
document
as
a
minimum
standard
set
of
reports,
you
know
are
there
other
reports
that
we
should
be
thinking
about?
Is
this
framework
gonna
cover
what
we
know
about
you
know.
There
are
a
variety
of
reasons
why
different
registries
might
produce
some
specialized
reports
for
their
registry
registrars
might
have
special
requests
that
registries
produce
for
them.
A
You
know
so
maybe
they're
not
part
of
a
standard
definition,
but
since
this
document
its
real
goal
is
about
defining
a
framework
for
managing
standard
reports
and
standard
columns.
We
really
want
people
to
be
thinking
about
what
other
reports
do
you
know
about
that
we
won't
put
in
here,
but
we
want
to
make
sure
that
technically
they
can
be
covered
by
this
framework
for
defining
them.
A
A
You
know
anybody
can
create
a
value
that
they
want
to
be
able
to
use
in
a
standard
report,
and
it's
just
mana
registering
and
it's
a
first
come
first
serve
registry,
so
it
operates
just
like
the
epp,
extensions
registry
that
exists,
and
that
seems
like
a
pretty
fair
way
to
do
it.
You
know
the
only
requirement
would
be
not
to
invent
a
column
that
already
exists,
and
you
know
for
the
the
iana
registry
itself
to
be
self-consistent.
Obviously
this
is
just
an
example
of
the
column
heading
registry.
A
So
if
the
slides
you've
seen
these
before
we've
been
just
carrying
these
forward,
this
is
the
complete
collection
of
data
elements
in
the
reports
that
are
currently
defined.
So
you
know
this
is
just
what
it
looks
like
and
they'll
be
they'll
be
defined
as
part
of
this
document.
So
the
registrant
is
the
isg
in
this
case,
since
it's
coming
out
of
an
rfc
and
then,
as
the
registry
of
reports,
you've
seen
these
slides
before
too
this
you
know
the
this
is
the
framework
in
in
order
to
define
a
report.
A
It's
a
first
come
first
curve
registry.
Just
like
the
column
headings
and
our
goal
here
in
this
document
is
to
define
you
know
kind
of
a
minimum
set
of
universally
acceptable
reports.
I
don't
really
want
to.
I,
I
think
it's
more
of
a
policy
question
as
to
which
reports
are
mandatory
or
not,
but
we
do
want
to
try
to
collect
the
definition
of
the
most
common
reports
that
are
probably
available
from
most
registries
for
most
registrars
and
that's
what
we're
trying
to
put
together
here.
A
I
think
the
key
thing
about
the
registry
of
reports
right
now-
and
this
is
where
we
got
into
one
of
the
open
questions-
is
about
whether
column
headings
are
optional
or
mandatory.
If
you
look
at
the
third
sub
bullet
there
under
the
report
registry
bullet,
it
says,
ordered
list
of
column
headings
in
the
report.
A
This
is
what
it
looks
like
the
report
registry,
and
so
an
important
question
here
is
whether
or
not
fields
are
mandatory
or
optional,
and
what
that
really
means
and
you'll
note
that
the
you
define
the
report
name
and
then
you
simply
list
the
fields
that
are
in
the
report
and
it's
intended
to
be
an
ordered
list
so
that
that's
the
way
row
one
in
a
given
report
would
always
appear
in
that
order.
A
But
there's
an
important
question
here
about
optional
versus
mandatory
that
we'd
like
to
get
some
feedback
on
and
just
confirm.
You
know
how
people
want
that
to
work
could
certainly
go
either
way.
A
lot
depends
on
on
how
we
want
things
to
to
work,
and
so
that
just
leaves
us
with
some
other
questions.
These
were
these
questions
were
originally
in
the
first
version
of
the
document
that
was
distributed
and
created.
We've
pulled
these
topics
out
of
the
document
based
on
feedback
we've
gotten
already
and
having
given.
A
You
know,
had
some
discussions
a
couple
of
times
here,
but
our
question
now
to
the
working
group
is:
what
to
do
with
these
things:
do
we
just
drop
them?
Are
they
suitable
for
some
other
specification
in
you
know
some
other
work,
so
those
really
are
the
two
choices.
I'm
assuming
here
that
they're
not
going
to
be
left
in
in
this
document,
since
we
pulled
them
out
one
of
the
doc.
One
of
the
things
that
we
had
put
in
the
original
document
was
okay.
A
If
I'm
going
to
create
a
standard
report
and
it's
going
to
be
in
a
file,
should
we
say
something
about
what
that
file
name
looks
like
or
not,
and
you
know,
there's
there's
there's
certainly
discussion
on
both
sides
as
to
whether
we
should
or
not.
This
is
what
we
had
proposed
in
the
in
the
original
document.
A
So
that's
a
question
that
we
want
to
put
to
this
group,
and
the
second
thing
is
again
also
with
respect
to
the
operation
the
when
the
doc
when
the
reports
are
published,
we
want
to
say
anything
about
what
that
mechanism
looks
like.
In
the
last
discussion.
We
clearly
had
said
that
we
didn't
want
to
say
it
in
this
document.
A
This
should
just
be
a
framework
for
defining
the
reports,
but
do
we
want
to
have
any
discussion
or
any
work
item,
maybe
in
a
separate
document
or
or
not
as
to
what
it
looks
like
when
these
documents
are
published,
what
the
mechanism
looks
like
or
mechanisms
that
can
be
used?
You
know,
there's
the
two
obvious
choices
are
sftp
related
or
https
related
mechanisms
and
then
talk
about
what
the
what
the
directory
looks
like.
A
So
that's
an
open
question
and
then
inside
of
the
fields,
I
think
this
is
probably
well
defined
as
probable
as
part
of
what
csv
defines,
but
it's
worth
calling
out
that
this
is
always
an
interesting
question
and
you
know
what
do
we
want
to
say
about
this?
In
particular,
this
the
detail
about
the
separator
character
between
columns.
A
Do
we
want
to
specify
what
that
is
precisely
and
then
you
have
to
deal
with
the
escape
mechanism
you
know,
or
do
we
just
want
to
leave
that
to
you
sorted
out
when
you,
when
you
load
up
the
csv
file
generally,
you
can
sort
of
figure
out
what's
going
on
there,
but
you
know
how
specific
do
we
want
to
be
about
that
in
terms
of
what
it
says
there
and
what
it
looks
like
our
feeling
is
you
can't
use
a
comma
as
a
separator
between
values
between
fields,
because
commas
are
used
inside
field
values,
so
you
know
what
do
we
want
to
specify
for
what
goes
between
them?
A
Different
people
do
different
things
and
and
how
to
manage
that,
and
we
should
probably
speak
to
that
issue
in
the
document,
and
I
think
that's
it
right
yeah,
that's
the
last
slide.
So
that's
it
so
open
discussion.
You
know
we
can.
I
guess
back
to
you
antoine,
for
how
much
time
you
want
to
spend
on
this
versus
taking
comments
to
the
mailing
list,
but
we
are
looking
to
move
this
along.
A
We
don't
have
a
document
shepard
for
this,
and
we
haven't
set
a
milestone
for
this
yet
so
those
are
open
questions
if
anybody
wants
to
to
speak
to
what
their
thoughts
are
on
that
here,
those
would
be
useful,
so
our
open
questions
and
and
any
any
comments
about
document
shepard
and
milestone
thanks.
Thank.
M
Thank
you,
yeah.
In
reviewing
the
draft
and
and
looking
at
what
you're
presenting
here.
I
believe
the
draft
should
be
focused
on
mechanism,
meaning
that
the
definition
of
concrete
reports,
I
think,
is
out
of
scope.
I
think
it's
best
that
it
focuses
on
the
format
of
these
reports
and
things
like
file,
names
and
transport
of
the
reports
I
think,
is
also
not
well
suited
for
this
either
I
mean
putting
metadata
in
the
file
name.
M
Is
it's
not
a
scalable
thing
and
we
could
be
using
a
rest
interface
as
well,
so
I
would
just
leave
it
to
format
if
all
possible
and
leave
it
on
the
mechanism
and
leave
the
concrete
reports
out
of
it.
Thank
you.
B
Okay,
now
then,
it's
up
to
me
to
ask
the
authors
of
course
of
when
they
want
to
have
their
milestones,
set.
A
I'm
thinking
that,
given
the
as
feedback
has
been
dropping
off
that
you
know
it
ought
to
be
reasonable
for
us
to
to
finish
on
this
document
sometime
this
year.
I'd
like
to
think
that,
with
a
couple
more
iterations
on
some
of
these
finer
details
here,
we
ought
to
be
all
set
to
go.
So
unless
there's
a
strong
objection
or
some
other
significant
comment
about
this
framework,
I
I'd
even
go
so
far
as
to
to
say
you
know
december
this
year,
late
this
year,.
B
Okay,
okay:
we
will
ask
this
question
again
on
the
mailing
list
as
well,
of
course,
and
also
are
there
any
volunteers
to
be
a
document
shepard
for
this?
B
A
Action
to
do
some
directory
outreach
to
see
if
we
can
get
someone
who
will
volunteer.
B
A
I'll
just
go
for
for
a
moment.
While
we
wait
to
see,
I
guess
no
one's
gonna
say
anything,
maybe
I'll
just
say:
we've
actually
had
a
pretty
good
cadence
going
this
working
group.
We
we
kind
of
had
our
our
ups
and
downs
and
and
we've
kind
of
hit
a
a
bit
of
a
good
cadence
going
here
with
a
with
a
few
documents
coming
out
the
door
pushing
some
things
along.
We've
got
some
new
stuff
here
which
is
going
to
move
along
quickly
too.
A
You
know
once
we
get
past
this
searching
in
the
registration
reporting.
I
I
don't.
I
don't
see
anything.
The
only
other
thing
left
on
the
agenda
is
the
open
id
stuff,
so
you
know
we
might
be
again
hitting
a
a
low
heel
or
or
maybe
we're
coming
to
to
the
end
of
our
our
our
life
if
we're
getting
into
a
good
place.
So
just
something
to
think
about
in
general
for
this
working
group,
since
we
generally
deal
with
extensions,
it's
not
clear
to
me.
A
If
we
would,
you
know,
maybe
we
need
to
be
available
here
or
or
not,
but
I
mean,
if
there's
nothing
obvious
in
front
of
us,
maybe
maybe
we're
coming
to
the
end
of
our
life
too.
So
that's
something
to
think
about.
I
Thanks
antoine
just
in
response
to
jim,
even
if
the
working
group
has
no
immediate
stuff
on
its
plate
for
work,
I
think
it
might
be
premature
to
talk
about
winding
the
working
group
up,
because
who
knows
what
stuff
might
every
medicine
I
can
at
some
point
in
the
future.
So
I
would
maybe
suggest
I
don't
know.
If
there's
practicalities
from
an
itf
point
of
views,
maybe
the
working
group
becomes
dormant
and
then
springs
back
up
to
life
as
and
when
I
can
throw
something
over
the
wall.
H
A
That
we
need
to
be
careful
not
to
set
ourselves
up
as
a
group
that
just
takes
on
icann's
work.
That's
a
phrase
that
tends
to
in
incite
various
feelings
in
our
working
group
with
with
some
participants.
A
A
But
I
take
your
point
nonetheless,
I
you
know
I,
I
guess
my
statement
was
a
little
bit
provocative
in
hopes
of
seeing
what
kinds
of
views
we
might
get
from
from
folks
in
the
group
here
as
an
as
a
working
group
that
is
looking
at
and
and
watching
for
extensions
in
both
rdap
and
epp,
dormancy
might
be
a
better
model
than
than
winding
down
the
working
group,
but
we'll
we'll
just
have
to
see
as
as
we
move
along
here.
Who
knows,
work
may
come
back
it
it.
A
It
might
be
a
little
bit
premature,
but
we'll
we'll
answer.
Ask
that
question
and
discuss
it
with
our
ad
as
as
time
goes
on
here
and,
of
course,
we're
always
interested
in
what
working
group
members
think
and
and
how
people
would
like
to
approach
this
problem
space
in
general
and
and
our
preparation
for
dealing
with
issues.
So
thanks
sorry,
didn't
mean
to
get
too.
I
Thanks
tim,
I
agree
wholeheartedly
what
you
said
jim,
but
I
do
think
we
might
need
to
think
about
this
dormant
working
group
thing,
because
if
there
is
an
itf
vehicle
for
things
of
a
technical
nature,
that
might
imagine
I
can
maybe
that
stuff
would
go
somewhere
else
and
not
get
the
benefit
of
its
scrutiny.
So
swings
around.
B
H
I'm
making
sure
you
guys
can
hear
me
this
is
jody
coulter
say
I
was.
I
was
just
wondering
we
have
a
registry
maintenance
draft
out
there,
it's
been
out
there
for
a
while.
We
have
a
milestone
of
july.
H
A
A
F
A
Was
putting
the
slides
together,
wow
thanks
jody
goodness?
Well,
let's
yeah
you're
right
jody,
that's
a
document
which
is,
it
seems
fairly
stable
too,
and
is
probably
ready
to
move
along
like
the
rest
of
our
documents
here.
So
the
only
thing
that's
required
really
for
for
for
last
call
is
that
someone
volunteered
to
do
that
now
that.
A
A
But
yeah,
unless
anyone
has
any
discussion
about
that
document
in
particular,
I
agree
with
you
jody,
it's
probably
ready
to
move
along,
so
we
simply
take
to
the
mailing
list.
You
know
a
request
to
go
to
working
group
last
call
and
then
move
that
document
along.
H
A
Yeah
and
it
is
actually
on
the
milestone
list
and
I'm
not
quite
sure
how
I
did
that,
but
you
know
given
that
it
is
on
the
milestone
list
and
it's
actually
listed
for
october.
You
know
that's
where
it
was
set
up,
but
unfortunately
I
managed
not
to
carry
that
forward
into
the
existing
work
discussion.
B
No
then,
I
think,
do
you
have
closing
remarks
jim
or
shall
I
just
close
the
meeting
and
say
thank
you,
everybody
and
hope.
We
will
soon
be
able
to
have
a
face-to-face
meeting
again,
but
seeing
the
circumstances,
I'm
still
doubting
whether
or
not
that
will
be
this
year
and
we
will
see
each
other
online
again
and
let's
discuss
on
the
mailing
lists.