►
From YouTube: IETF103-REGEXT-20181106-1350
Description
REGEXT meeting session at IETF103
2018/11/06 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
B
B
All
right,
we
are
right
on
time
here
by
my
clock
and
my
clock
is
right:
I'm
sitting
in
the
chair
seat
AHA,
this
is
the
registration
protocol.
Its
extensions
working
group
welcome
to
everyone.
We
I'm
James
Galvin,
one
of
the
co-chairs
Antoine
for
sure
and
is
up
there
in
our
meet
echo,
also
participating
along
with
with
a
few
other
folks,
and
so
the
first
thing
is
the
mic
on
there's
no
way
for
me
to
turn
it
on
and
off
am
I
not
close
enough
to
it.
That's
much
better!
B
Okay
eat
the
microphone
is
the
breeze
I
have
to
make
sure
I
stay
close
enough
to
it
here.
Okay,
this
is
the
standard
note.
Well,
you
know
please
do
take
note
here.
B
B
Document
review
request:
this
is
just
a
generic
slide
that
we
like
to
put
up
just
to
remind
people.
This
working
group,
especially
we
are
a
relatively
small
group,
and
we
do
struggle
sometimes
with
making
sure
that
we
get
reviews
of
documents
and
people
to
acknowledge
that
it
is
important
to
even
indicate
a
plus-one
when
you
support
a
document
or
if
you've
got
a
comment,
please
make
it.
B
Of
course,
we're
always
looking
for
document
shepherds
and
you
don't
have
to
have
any
experience,
but
please
do
that
and
and
in
general
it'll
be
kind
to
other
working
groups.
Sometimes
it's
nice
to
have
other
people
acknowledge
your
your
your
your
documents
and
please
do
the
same
for
other
people
in
other
groups.
B
Okay,
we
have
a
very
full
agenda
today
we
have
quite
a
bit
of
documents
to
go
through
and
review,
so
this
is
really
a
good
thing
for
us
here.
We've
been
quite
productive
here
since
the
last
IETF
beam
moving
documents
along
and
clearing
milestones
and
such
and
we'll
get
to
talking
about
all
those
details
as
we
get
through
the
day.
B
Anybody
want
to
jump
in
and
offer
a
particular
change
to
these
major
categories
here
for
our
agenda
and
there's
always
a
slot
at
the
end
for
people
to
bring
up
anything
new
and
an
extra
that
they
want
to
add
so.
Okay,
let's
just
jump
right
in
here,
welcome
and
introductions.
We
do
have
a
jabber
scribe.
Thank
you
very
much,
an
anode
scribe.
Thank
you
again
and
we'll
take
a
moment
here
to
talk
about
our
terminal
date
so
very
quickly.
B
The
Charter
remained
with
two
items
which
have
always
been
there
since
the
beginning,
which
is
that
the
responsibilities
of
this
working
group
is
to
deal
with
EPP
and
our
DAP
extensions
that
are
proposed
for
the
standards
track.
So
this
working
group
will
get
ownership
of
those
and
most
of
the
work
that's
coming
in
front
of
us
seems
to
fall
into
that
category
and,
of
course,
we
started
out
way
back
when,
with
a
dozen
or
so
documents
that
were
on
our
list
and
we're
finally
getting
those
cleared
out
of
the
way.
B
But
the
review
is
generally
about
making
sure
the
document
itself
is
self
consistent
and
then
it's
allowed
to
be
on
the
Ayana
registry.
The
big
change
that
was
important
to
this
working
group
was
to
set
ourselves
up
to
be
able
to
address
some
new
documents,
some
new
tech
them
with
technical
proposals
that
are
needed
in
the
ICANN
context
for
registries
and
register
our
son
for
the
use
of
EPP
and
our
DAP.
B
You
know.
Historically,
you
know
the
technical
work
is
done
here
in
the
ITF.
Icann
focuses
on
policy
considerations
and
when
there
are
policy
considerations
that
have
implementation
choices,
there's
actually
a
Technical
Operations,
Group
and
I
can
that
is
working
through
some
technical
issues
and
then
the
objective
is
to
use
the
IETF
process
to
be
to
be
part
of
the
IETF
process
to
bring
those
documents
here.
The
IETF
gets
change.
Control,
of
course,
get
broader
review.
B
The
broader
community-
and
you
know,
move
those
documents
into
an
appropriate
publication
stage,
either
standards
track
or
perhaps
informational
best,
current
practice,
whatever
is
appropriate,
so
that
there's
a
technical
documentation
for
it.
We
actually
had
to
negotiate
back
and
forth
a
couple
times
with
the
isg
to
make
sure
that
we
scoped
those
suggestions
and
in
a
proper
way.
There
is
a
lot
of
concern
about
leaving
the
Charter
to
be
open-ended.
B
We
we
did
our
best
here
to
try
and
keep
that
under
control,
and
hopefully
this
accomplishes
that
those
three
bullets
they're
about
what
we
can
do
and
we'll
see
some
of
these
in
the
working
group
adoption
in
the
in
the
list.
At
the
end,
when
we
start
talking
about
new
documents,
we
we
now
are
set
up
to
take
on
some
of
those
new
documents
based
on
these
mullux
that
are
here
any
questions
about
our
Charter
update.
B
Okay,
moving
along
document
management
is
that
sneaky
little
slide
we
stuck
in
the
beginning
before
we
got
to
the
agenda,
so,
let's
move
to
existing
document
status,
we're
actually
in
a
pretty
good
place.
Here
we
have
two
documents
currently
sitting
and
the
RFC
editor
queue.
I,
don't
know
that
there's
much
to
say
there,
except
that
the
reviews
are
in
progress
and
document
editors
are
keeping
up.
B
But
let
me
give
the
opportunity
to
document
editors
if
you
want
to
add
something
or
say
something
more
about
these
two
documents
allow
people
in
microphone
and
I
have
to
keep
an
eye
on
this
remote
participation
see
if
anybody
jumps
in
the
queue
there.
Okay,
I'm
gonna
move
those
past
those
fairly
quickly.
Here
then,
we
have
four
documents
and
iesg
evaluation
and
I'm
sorry
I
misspoke
before
RFC
editor,
Q,
that's
really
a
final
process
kind
of
thing.
B
That's
really
just
the
document
editors
working
with
the
documents,
the
isg
review
is
where
there
are
documents
where
the
document
editors
are
working
through
comments
from
the
isg
and
getting
those
documents
ready
to
go.
I
believe
change
poll
is,
is
in
a
really
good
place
and
it's
ready
to
go.
The
org
drafts
are
sitting
waiting
for
a
new
revision
of
those
drafts
to
be
published.
B
The
editors
have
taken
on
comments
from
the
isg
and
they
have
to
issue
a
new
internet
draft,
a
new
version
or
the
isg
to
progress
it
and
the
fee
extension
actually
just
had.
The
new
version
of
the
internet
trap,
published
I
think
it
was
Friday,
might
have
been
a
couple
days
before
that,
but
in
the
recent
past
week
here
we
got
the
new
version
that
the
ISU
was
waiting
for.
B
So
that's
now
available
for
that
to
move
along
and
press,
so
that
takes
care
of
quite
a
length,
a
number
of
milestones
that
we
had
on
our
list.
It's
probably
worth
pointing
out
at
this
point
that
one
of
the
things
that
happens
is
once
a
document
is
submitted
for
publication.
We
get
to
take
it
off.
Our
milestone
list,
so
these
documents
don't
currently
appear
on
the
milestone
list,
including
the
one
in
the
RFC
at
interview
and
that's
an
important
bit
of
formality
and
administrative
characteristic
just
to
notice
for
people
about
all
these
documents.
B
So
that's
a
good
thing
for
us.
Do
those
editors,
it
all
want
to
say
anything
about
their
documents,
all
allow
folks
a
chance.
If
you
like.
Yes,
these
guys,
you
can
speak
from
the
microphone
there.
Yeah.
C
C
C
The
same
thing
held
for
the
change
poll
as
well.
The
main
criteria
is
the
fact
that
you
have
production.
Implementations
of
this
change,
the
name
space
will
be
impactful,
so
I
would
highly
recommend
that
the
editors
and
the
implementers
of
these
particular
extensions
speak
up
related
to
changes
or
impacts
of
XML
namespaces,
but
I
could
speak
for
the
change
pol
I
knew
that
that
would
be
impactful,
so
in
general,
I
think
we've
been
doing
a
good
job
related
to
certain
to
scope.
C
B
Thank
you
for
that.
Actually,
that's
a
that's
a
really
good
point
and,
as
you
said,
I
think
we've
been
handling
that
and
managing
it
and
not
aware
of
any
concerns
within
the
isg
about
it.
It
all
seems
to
be
under
control,
but
going
forward.
We
should
be
more
careful
and
you
know
we'll
just
let
these
that
we
have
here
go
through
as
needed,
we'll
bring
up
the
issue
and
make
a
deliberate
decision
about
what
we're
doing
any
other
comments
or
questions
from
anyone
about
these
set
of
documents.
Here.
B
Ok,
then,
we'll
move
to
the
last
one.
Here
we
have
one
document
on
our
milestone
list,
which
is
waiting
for
the
shepherd
right
up.
There
actually
is
in
fairness.
There
is
a
draft
shepherd
right
up
for
this
that
exists,
but
it
it
has
not
been
posted
yet
because
it
needs
to
be
reviewed.
The
chairs
have
to
comment
back
to
the
relatively
new
document
shepherd
about
making
some
editorial
changes
to
his
document.
B
It's
in
sort
of
this,
his
write
up
is
in
sort
of
an
odd
form,
and
we
want
to
clean
that
up
before
we
submit
it
to
the
iesg
for
consideration,
but
it's
actually
ready
to
go,
and
so
hopefully
this
document
will
be
off
our
milestone.
This
shortly
and
you'll
see
that
as
we
get
to
the
end
and
I'm
looking
okay
I
don't
see
the
document
Shepard
in
our
remote
participation,
so
we'll
just
move
on
from
there.
Okay
moving
right
along,
let's
jump
to
a
discussion
about
the
Human
Rights
review.
B
I
want
to
start
first
by
making
a
comment
here,
which
is
is
kind
of
important.
We
there's
been
some
discussion
on
the
mailing
list
about
Human
Rights
reviews
of
our
drafts
and
there's
been
quite
a
bit
of
discussion
about
one
draft
in
particular.
Some
comments
that
were
provided
to
us
I
think
that
on
one
of
the
advice
that
we've
gotten
in
having
communicated
with
our
area
director,
it's
as
a
reminder
to
us
it's
useful
to
keep
in
mind
that
these
Human
Rights
reviews
are
really
just
individual
contributions
and
I.
B
Think
that's
a
really
important
point
for
people
to
keep
in
mind.
There
is
no
extra
formality
associated
with
the
fact
that
there's
an
HR
PC
research
group,
which
is
looking
at
these
issues,
human
rights
issues
in
a
broader
context.
They
are
actively
engaged,
as
as
a
group
and
representatives
of
that
group
are
going
forward.
You
know
with
some
documents
and
and
making
some
notes
and
making
contributions
to
document
editors
about
them.
B
But
I
think
that
it's
important
for
our
own
context
and
for
the
work
that
we
have
to
keep
in
mind
that
we
should
treat
them
as
we
would
any
other
individual
contribution.
And
with
that
in
mind,
I
want
to
first
let
James
Gould
come
up
and
talk
about
the
document
and
the
review
that
he
received
and
what
he
did
with
that
and
then
we'll
have
any
additional
conversation
from
the
working
group
about
reviews
in
general
and
this
particular
documents
review.
C
Thanks
Jim,
so
this
Jim
Gold
from
Verisign
in
reviewing
the
feedback
received
I,
did
identify
one
applicable
feedback
that
was
important
one
and
in
particular
what
this
was
was
that
there
was
normative
language
in
the
extension
that
required
the
vsp
to
store
the
data
that
was
verified.
I
agree
that
that
was
a
little
bit
of
an
overreach.
What
was
absolutely
necessary
for
the
verification
of
code
extension
to
work
was
at
the
VSP
store
proof
of
verification
in
a
store.
C
The
data
that
was
verified,
but
what
was
added
to
the
security
considerations
section
was
that
any
data
stored
by
the
VSP
must
follow
the
applicable
privacy,
privacy,
laws
and
regulations.
So
in
essence,
the
idea
here
is
the
fact
that
the
verification
code
extension
is
simply
a
pointer
and
proof
that
verifications
perform
any
collection
of
data.
C
Any
verify
is
up
to
the
VSP
and
there
was
no
a
reason
for
the
draft
to
imply
a
particular
approach
for
storing
that
data,
so
that
was
the
only
relevant
feedback
that
I
shouldn't
see
that
was
incorporated
in
the
draft
and
with
that
I
will
be
requesting
for
a
working
group.
Last
call
on
this.
After
we
go
through
this
discussion,
please.
D
Go
ahead,
go
Sabbath,
global
Center
for
Internet
and
Society,
so
I
have
a
disagreement
that
it
was
not
the
only
technically
consideration
from
the
review.
In
my
opinion
and
the
obligation
on
the
verification
service
provider
to
follow
the
privacy
and
data
security
guidelines
is
rather
inconsequential.
Like
drafts
generally,
don't
have
advice,
please
follow
laws
right,
but
in
any
case,
I
think
there
are
some
pending
issues
for
the
working
group
to
consider
and
I.
D
Think
the
first
one
is
whether
what
document
status
intended
document
status
the
RFC
will
have
if
this
is
published
in
D
so
and
to
my
own
standing
from
RFC
375.
That
largely
depends
on
the
number
of
use
cases
and
how
how
widely
deployed
this
extension
will
be,
and
there
was
a
discussion
about
this
on
the
mailing
list,
and
if
this
document
has
limited
use,
then
it
RFC
three
735
provides
the
option
to
document
it
separately
and
not
as
an
RFC.
C
Make
one
comment
and
I
know
that
Scott
will
I
jump
in
on
this,
but
no
this
is
generic.
This
is
of
general
applicability,
I
mean
actually
in
the
last
update.
We
included
implementation
status.
Information
into
the
draft,
so
you'll
see
the
fact
that
there
are
multiple
independent
implementations
of
this
particular
draft.
So
from
a
process
perspective
I,
like
Scott,
jumping.
E
Scott
on
making
not
really
a
process
comment
I'm.
The
author
of
that
particular
document
and
I
can
speak
to
what
the
text
actually
says.
It
does
describe
the
fact
that
you
know
extensions
may
be
documented
as
either
proposed
standards
or
informational
documents
or
not
IETF
documents
at
all,
but
nothing
in
there
is
a
mandate
to
describe
that.
One
extension
should
be
published
one
way
or
another
and
there's
no
text
in
there
that
says
anything
about.
You
know.
Broad
applicability
means
that
you
know:
thou
shalt
not
be
proposed
standard.
D
I
have
no
disagreement
on
how
to
interpret
that
Clause.
I
would
just
like
to
quote
it
for
the
context
of
the
working
group.
The
intended
maturity
level
information
is
,,
proposed
standards,
etc.
Largely
depends
on
what
is
being
extended
and
the
amount
of
general
interest
in
that
extension
I
agree
that
it
does
not
date
any
level
for
document.
It
does
not
provide
any
prescriptions,
but
I
would
take
the
document
as
at
least
recommend
a
tree
in
nature.
B
So
yeah
the
document
is
a
standard
track
document.
So
what
it
is?
You
brought
up
the
question
that
you
have
some
additional
concerns
additional.
You
believe
there
are
additional
technical
concerns
in
the
review
that
was
provided
that
you
believe
were
not
addressed
by
James's
revision
to
the
document.
Yes,
ma'am,
okay,
so
yeah.
Let's
talk
about
what
those
are.
Let's
have
that
discussion
yeah.
B
C
D
Hope
everyone
has
read
the
draft
and
yes,
so
there
is
this
grace
period,
which
is
given
to
the
VSP
to
reply
with
an
either
either
the
verification
code
or
not.
So
the
draft
does
not
define
the
behavior
when
the
VSP
has
not
responded
with
the
verification
code
in
this
grace
period.
So
this
details
are
actually
not
in
the
draft,
but
in
the
pattern
which
is
associated
with
the
dart
file
by
Verisign,
Inc
and
I.
Think
this
is
important
info
which
should
be
in
the
draft.
Can.
C
I
respond
to
that
please,
the
grace
period
is
not
associated
with
the
VSP
at
all
the
grace
period
associated
with
the
registry
itself.
So
if
the
registry
does
not
receive
a
particular
type
of
verification
code
within
a
particular
time
frame,
it's
up
to
server
policy
relating
to
what
action
they
take
again.
This
is
going
into
policy.
The
verification
code
draft
will
not
try
to
imply
or
recommend
a
particular
policy,
not
ever
so
in
essence,
I'm
really
careful
related
to
separate
policy
from
mechanics
open.
The
draft
I.
D
C
In
this
case,
it's
actually
by
design
the
we
don't
want
the
verification
code
extension
to
define
a
particular
server
policy,
in
essence,
we're
enabling
the
ability
of
verification
codes
being
passed
and
allow
for
the
servitor
to
find
what
those
grace
periods
may
be
based
on
the
verification
code,
types
that
are
supported.
So
in
essence,
it
defines
what
the
grace
periods
are
within
the
draft,
but
again
when
we
get
to
actually
defining
what
those
grace
periods
and
what
the
actions
of
the
server
will
do
if
they
expire
it's
completely
up
to
server
policy.
So.
B
A
C
B
D
C
D
D
The
second
one
is
the
integrity
of
the
object
when
it
goes
to
the
VSP
and
comes
back
so
I
think
the
document
should
define
that,
so
the
integrity
is
maintained
when
it
goes
to
the
VSP
and
the
integrity
of
the
verification
code
is
maintained
when
it's
back,
but
both
the
prescribed
action
should
be
that
the
object,
the
fields
and
data
should
shouldn't
be
forwarded,
as
received
by
the
VSP,
but
actually
should
be
matched
with
what
was
submitted
by
a
registration
registrant.
Let's
say:
oh
you're.
D
A
A
C
D
C
D
D
C
D
C
A
C
In
essence,
if
you're
saying
that
the
Registrar
should
be
the
one
to
ensure
that
it
matches
up
it's
their
responsibility
to
do
so
right,
so
it's
in
the
language
of
the
draft
would
be
the
clients
responsibility
to
ensure
that
the
verification
code
matches
up
with
the
object
that
is
being
created
or
updated
in
the
registry.
Okay,.
D
D
The
third
thing
which
was
suggested
on
the
list
is
that
the
effects
of
implementing
this
should
be
as
clear
as
they
can
be
and
to
different
individuals
have
suggested
that
there
might.
There
should
be
a
human
rights
consideration
section
in
the
document
and
I,
don't
know
if
the
individuals
are
here:
Adam,
Roach
and
Andrew
Sullivan.
C
Well,
let
me
respond
to
that
first
off
that
I
have
concern
related
to
mixing
in
policy
again
with
the
mechanics,
so
this
is
you're
asking
for
hold
on
if
you,
if
policy
and
mechanics.
So,
if
you're
asking
for
me
as
the
document
editor
to
put
human
rights
considerations
into
the
draft,
that's
moving
into
policy,
this
has
to
be
the
mechanics.
So
if
you
have
any
recommended
text
to
add,
I
saw
a
request
as.
D
B
So
let
me
just
jump
in
here
a
little
bit
to
put
this
in
a
you
know,
kind
of
context,
I
think
that
I
want
to
say
two
things.
First,
we
have
we've
addressed
what
we
know
to
be
technical
concerns
with
this
document
right
so,
except
the
duty
I
pointed
out,
except.
F
B
B
I
want
to
I
want
to
tease
apart
your
item
three
into
into
two
parts
and-
and
that
is
I'm
sure
that
what
Andrew
and
Adam
were
suggesting
is
that
if
there
is
to
be
human
rights
sections,
if
there's
to
be
human
rights
issues
to
be
addressed,
that
there
could
be
a
section
that
held
that
I'm
fairly
certain,
they
were
not
saying
that
this
document
should
have
a
human
rights
section.
Man
in
the.
D
D
B
D
B
B
B
Okay,
so
let
let's
get
some
other
voices
in
in
the
discussion
here
and
see
where
we
want
to
go
I.
Think
the
important
question
here
for
the
group
as
a
whole
to
decide
is
whether
these
considerations
are
something
that
belong
in
the
document
or
not,
and
that's
for
working
group
consensus
and
in
that
spirit,
Oh,
Andrew
and
Adam
are
just
speaking
as
individuals,
but
it
is
for
the
the
group
as
a
whole
to
decide
what
they
do
or
don't
want
to
do
with
the
document.
Oh,
please
go
ahead.
Hi.
G
Nielsen
/
University
of
Amsterdam
I'm
very
happy
we're
actually
having
this
discussion
and
that
we're
working
on
the
draft,
because
this
discussion
has
been
going
now,
I
think
for
well
over
a
year,
maybe
one
and
a
half
year
and
when
I
first
brought
it
up.
James
asked
whether
we
could
suggest
text
well,
we've
done,
we've
done
the
reviewed
and
we've
started
the
meeting
as
well
with
a
request
for
reviews
and
that's
what
we've
done
so
I'm
very
happy
we're
engaging
in
the
process,
as
as
it
should
be.
G
I
also
really
hope
that
different
parts
are
taking
to
accounts.
It
I
think
there
is
some
mischaracterizations
about
how
all
points
in
the
review
have
been
addressed
and
they
can
be
addressed
better
and
I.
Think
there
is
space
for
that
on
the
list.
I
do
hope
that
we
can
actually,
because
that's
all
our
discussions
started
then
we
actually
document
that
part
of
that
discussion
and
the
implications
in
it
draft
and
then
it
could
actually
make
sense
for
us
also
support
a
publication
of
it
because
then
it
would
then
people
would
still
have
a
choice.
G
I
think
proposed
standards
going
a
bit
far,
but
then
there,
the
you've,
shown
the
implementations
there
proposed
standard
might
still
be
a
go
a
bit
far,
but
if
I
think
then,
if
the
the
the
trade-off
is
you
clearly
enumerate
the
implications
of
that,
then
that
would
make
sense.
I
think
that's,
that's
a
that's
a
that's
a
fair
balance.
We
could
live
with.
So
it's
also
a
game
of
give
and
take
to
build
consensus
rights
in
which
everyone
is
equally
unhappy.
E
Hollenback
so
gur
shabad
mentioned
by
comparing
this
to
security
considerations,
sections
I'd
like
to
draw
one
very
significant
distinction:
we
have
documents
representing
IETF
consensus
that
give
us
guidelines
for
writing
security
considerations,
sections
Ayana
considerations,
sections
internationalization
considerations,
sections
etc.
We
have
no
such
documentation
that
represents
IETF
consensus
for
documenting
human
rights
protocol
considerations
and,
as
a
document
author
myself,
I
would
be
somewhat
at
a
loss
for
you,
no
guidance
on
what
kind
of
text
is
necessary
and
appropriate
here.
E
I,
don't
know
that
this
document
should
be
the
what's
the
word,
the
the
test
case
for
developing
such
text.
I
think
I'd
really
like
to
see
this
conversation
taken
up
at
a
level
above
this
working
group,
so
that
we
get
a
better
sense
of
you
know
the
ITF
consensus
on
how
and
when
and
if
this
kind
of
text
should
be
expected
to
be
incorporated
into
documents
in
general.
H
Thank
you,
hi,
yes,
I
think
when
we
all
sit
at
the
plenum-
and
let
me
hear
this-
you
know
the
surveillance
is
an
attack
on
the
internet
and
the
ITF
is
doing
something
against
it
and
we
protecting
everything.
We
all
applaud
it.
And
now
this
is
the
point
where
we
you
know
when
it
comes
down
to
do.
We
really
do
the
work.
H
Are
we
willing
to
you
know
not
just
clap
our
hands,
but
when
it
comes
down
to
it,
do
the
work
and
I
think
this
is
one
of
the
points
where
we
have
to
sit
down
and
say
yeah?
Maybe
we
just
documented
that
might
be
even
enough.
So
it's
not
that
much
that
he
asks
of
us
to
do.
Do
you
know
to
come
forward
with
this?
It's
not
much,
but
it's
a
first
step
and
I,
don't
see
why
we
wouldn't
do
it.
B
Before
we
move
on
and
start
you
over
again
here,
I
do
want
to
say
that
it
is
you.
You
bring
up
an
important
point
in
wanting
to
reiterate
or
emphasize
that
some
of
the
elements
of
the
review
you,
you
believe
that
they
do
have
a
place
in
the
document
and
that
they
should
be
covered
and
that
they
weren't
and
I
think
that
we're
not
going
to
be
able
to
make
that
final
decision
here.
That
is
something
that
we
should
bring
to
the
list.
I
think
as
James
had
suggested
before.
B
It
would
be
good
to
separate
they.
We
know
to
be
the
technical
issues
that
we
talked
about
and
it
seems
like
we
result
and
then
we
can.
We
can
start
a
bit
of
a
discussion
about
the
items
that
you
think
should
be
incorporated
into
the
document
and
and
we're
not
at
this
point
in
time-
and
you
know,
let's,
let's
try
and
get
that
discussion
going.
It
is
for
this
working
group
to
decide
what
does
or
doesn't
get
added.
So
the
document
editor
gets.
You
know
first
dibs
at
deciding,
and
he
incorporates
things
that's
great.
B
If
he
doesn't,
then
we
ultimately
need
to
have
a
discussion
here
and
for
the
working
group
to
decide
collectively
that
they
agree
that
something
should
or
should
not
be
added.
So
we'll
try
to
allow
we'll
let
the
queue
run
out
here
again
and
then
probably
have
to
take
this
to
the
mailing
list.
We
don't
want
to
over
take
too
much
time
here,
but
we
can
take
on
the
mailing
list
further
discussion
and
seek
some
working
group
consensus
on
whether
or
not
to
add
any
new
remaining
elements.
Please.
G
Go
ahead
Nielson
over
University
of
Amsterdam,
so
it
was
my
understanding
that
once
a
document
is
adopted
by
a
working
group,
the
changes,
the
the
right
of
change
is
held
by
the
working
group
and
not
by
the
author
right.
So
I
first
I
want
to
reiterate
as
well
that
the
implications
of
technology
and
understanding
them
is
not
policy.
That's
that's
a
separate
thing,
so
I
think
we
should
not
characterize
the
implications
as
as
policy
work.
Next
to
that,
I
Scott
made
a
great
great
comment
that
security
considerations
are
our
ITF
consensus.
E
G
Okay,
great
and
but
furthermore,
if
you,
if
we
you
want
to
discuss
this,
I,
really
think
that
you
should
bring
this
up
at
the
plenary
and
see
if
we
could
see
community
consensus
for
integrating
human
rights
raishin.
That
would
be
great
great
support
or
if
you
bring
that
up
and
having
that
discussion,
because
I
think
it's
a
discussion
that
should
be
had
that
should
be
had,
like
you
said,
80
to
80
yeah
82.
G
C
This
Jim
go
from
Verisign
I
have
read,
I,
think
most
of
that
RFC
and
I
gotta.
Tell
you
right
now
that
I,
as
the
document
editor,
is
unqualified,
to
provide
any
input
into
the
draft
that
would
match
that
particular
RFC.
So
yeah
I
just
want
a
second
to
Scotts
opinion
on
this
is
the
fact
that
it
should
be
elevated
up.
I
do
not
want
the
verification
code
drive
to
be
a
guinea
pig
for
this
particular
activity,
so
I'm
hoping
that
so
my
point
is:
is
that
there's
no
other
graph
that
has
these
I'm?
Sorry
I'm?
C
F
Did
this
is
just
from
sorry
for
montón,
for
you
know
a
while
ago,
but
the
discussion
was
happened
on
item
three,
so
let
it
go
on
first
on
item
two:
you
wanted
the
clarification.
What
the
attack
scenario
was
that
they
were
trying
to
avoid.
This
was
about
the
modification
between
the
registry
and
the
registrar,
so.
B
B
C
G
I
Hello
and
morganator
a
brief
comment:
I
think
that
I
have
two
two
opinions
on
that.
The
one
is
some
language
in
the
draft
is
definitely
overreaching.
You
know,
as
we
discussed
before,
like
requiring
storing
personal
information
and
so
on
the
divorce
so
and
on
the
other
hand,
I
also
understand
that,
given
all
the
sort
of
like
obligatory
consideration
sections
that
we
need
to
write
the
new
read
draft,
we
use
a
draft
writer
myself,
adding
another
one
is
like
frustrating,
sometimes
yeah.
Yes,.
B
Well,
the
formality
of
having
a
required
consideration
section
is
certainly
an
IETF
policy
discussion
which
is
beyond
the
scope
of
this
working
group.
This
working
group
can
focus
on
whether
or
not
it
believes
that
the
issues
being
raised
belong
in
this
document
or
not,
and
then
I
do
think
that
you
know
the
folks
bringing
the
issues
to
the
floor
here
should
also
be
the
ones
that
bring
it
to
the
IETF
plenary
if
they
want
to
press
on
it
being
an
IETF
policy,
but.
I
B
That
would
be
happy
to
do
that.
Okay.
Thank
you.
The
most
important
thing
that
I
want
to
separate
out
in
this
discussion
is
the
broader
IETF
policy
discussion.
That's
that's.
A
separate
thing
should
be
brought
to
ITF
plenary
or
some
other
form
H
RPC.
The
research
group
can
have
that
discussion
and
in
its
relationship
with
the
IR
with
the
iesg
and
such
about
how
to
go
forward
with
all
of
that.
B
It
is
important
that
in
this
working
group
we
only
focus
on
whether
or
not
you
know
the
specific
text
being
offered
belongs
in
this
document,
or
not
that
if
people
are
agreeable
to
that,
okay,
okay
and
no
one
in
the
remote
queue
okay.
So
let's
move
on
to
our
agenda
here
new
candidate
documents
for
adopting.
We
have
quite
a
long
list
here.
There
is
currently
six
on
this
list
and
we're
going
to
take
a
few
minutes
to
go
through
each
of
these
documents.
B
J
K
Hello,
everybody
I
am
Mario
Fredo
I'm,
a
researcher
of
National
Research
Council
of
Italy,
but
today
I
speak
on
behalf
of
dotty
registry.
This
presentation
is
about
to
adapt
drafts,
namely
sorting
and
paging,
reverse
search
that
the
authors
consider
mature
enough,
hopefully
worthy
or
being
adopted
by
the
working
group.
Next
can.
B
I
K
K
The
that
has
inspired
the
first
draft.
That
is
also
the
main
reasons.
The
main
reason
for
the
adoption
is
well-known.
A
search
query
in
adapt
can
return
larger,
that
set
that
can
be
truncated
due
to
server
limits,
but
despite
this
fact,
adapt
does
not
provide
the
user
with
any
capability
for
restricting
the
results
set
in
in
any
way.
Returning
the
total
number
of
objects
found
nor
the
to
evaluate
the
accuracy
of
the
query
specifying
the
possible
sort
criteria.
K
Starting
from
the
identification
of
those
are
the
inefficiencies
the
authors
defined
the
formal
parameters
in
the
query
string
count
that
allows
the
user
to
attain
a
total
number
results,
sorts
that
enable
result
sorting
and
the
limit
and
offset
to
guerra
implemented
pagination
in
the
last
version
of
this
document,
and
new
properties
have
been
added
to
the
standard
response
memory
sorting
metadata
that
includes
information
about
the
current
bought.
Both
the
current
and
available
sort
criteria
in
paging
metadata
that
includes
a
total
number
is
at
am
paging
information
in
the
first
version
of
this
document.
K
K
The
server
must
add
an
appropriate
value
in
the
adapter
conformance
array
and
alternative
to
the
offset
pollination
in
version
subsequent
to
the
needs
of
proposal
cárcel
base
pollination
has
been
described,
so
a
new
parameter,
query
parameter
has
been
defined
the
day
this
new
parameter
is
called
Carter
and
Carter
is
an
opposite
ring,
representing
a
logical
pointer
to
the
first
result
of
the
next
page.
So
this
specification
includes
two
different
methods
or
pagination.
K
Next,
please,
this
slide
shows
the
comparison
between
the
two
methods
o
pagination,
the
main
advantages
of
offset
is
that
is
materially
supported
by
the
basis,
and
it
provides
maximum
flexibility
in
the
in
usage,
but
it
does
not
scale
well
for
large,
very
large
errors
at
set
and
is
not
suitable
for
real-time
data.
However,
this
does
not
seem
the
case
of
data,
because
registration
data
are
not
frequently
very
frequently
updated.
K
On
the
other
end,
the
cards
or
baseball
generation
scales
well,
but
is
difficult
to
implement,
is
not
flexible
because
you
cannot
select
any
portion
of
the
result
set.
You
have
to
scroll
the
result
set
from
the
beginning
and
they
is
not
very
compliant
with
the
presence
of
a
sort
operator.
For
these
reasons
it
could,
it
could
be
considered
impractical
and,
in
this
case,
I
think
that
not
the
provider
must
wonder
if
it's
really
Worf
implementing
this
method.
K
So
we,
which
is
the
the
best
method
to
appear
in
possible,
adapt
specification
or
if
the
two
methods
can
coexist
in
the
same
are
the
deployment
ation.
We
think
that
should
be
points
of
discussion
within
the
working
group.
Another
point
of
discussion
is
that,
if
the
described
in
metal
but
meta
data
should
be
part
of
a
more
general
meta
data
section,
including
other
contents,
for
example,
rate
limits
or
information
about
the
server
and
the
response.
B
Okay,
before
we
get
to
reverse
search,
so
one
thing
that
I
should
have
said:
I
apologize
when
we
started
this
section
about
working
group
documents
is.
The
purpose
of
this
discussion
is
not
actually
to
resolve
our
issues.
This
is
really
about
presenting
the
documents,
get
some
clarity
and
whether
you
understand
them,
you
know.
Do
these
questions
make
sense.
Do
you
I
mean?
Do
you
agree
that
these
are
valid
questions?
We
don't
actually
have
to
answer
them
and
solve
them
now.
B
But
if
you,
if
you
want
to
make
sure
that
you
understand
the
questions,
that's
appropriate
and
you
know
you
do
and
we'll
go
from
there,
because,
since
these
are
not
actually
working
group
documents,
yet
the
next
step
is
going
to
be
about
talking
about
which
documents
to
adopt
you
might
consider,
if
you
presume,
has,
of
course,
you
know,
read
these
documents
and
you're
and
you're
prepared.
If
you
have
additional
questions
that
you
want
to
highlight
and
and
raise
at
this
point,
we
can
capture
those
and
in
the
minutes
so
that
we'll
have
them.
B
K
B
K
That
reverses
is
a
service
that
is
provided
by
many
web
applications,
but
utterly
registry.
Already
performer
alert
search
is
because
the
Registrar
used
usually
altar
band.
A
solution
to
obtain
the
list
of
domain
names
related
to
other
registration
objects,
lightening
servers
or
contacts,
and,
in
addition
to
that,
there
are
some
requirements
coming
from
icon
in
this
lab.
I'll
put
two
extracts
from
two
documents:
suggestions
already:
the
implementation
of
reverse
search
capability
in
northern
registry
directory
services.
K
There
are
two
main
objections
that
have
been
raised
in
the
past:
against
implementation
or
reverse
searches.
One
is
the
can
cause
potential
privacy
risks
risks,
but
I
can
itself
points
out
that
reverse
search
is
allowed.
When
is
driven
by
some
permissible
purposes,
it
can
be
performance
and
control
situations,
and
we
all
know
that
a
DAP
relies
on
function
of
other
protocol
layers
to
enforce
security
so
to
to
provide
this.
This
controller
condition
there
are.
K
There
is
another
object,
objection
that
that
is
the
impact
on
several
processing,
but
we
know
that
our
top
already
support
searches
and
they,
the
import
reverse
searches,
is
absolutely
comparable
with
that
that
one,
you
two
standard
searches.
In
addition,
we
can
mitigate
this
impact
by
implementing
other
capabilities
like
sorting
and
paging
the
partial
response
and
filtering.
G
C
K
B
Actually,
let
me
suggest
that
we
not
have
a
discussion
about
whether
or
not
GDP
are
does
or
does
not
apply
to
this.
We,
we
have
a
technical
feature
that
we
need
and
whether
or
not
this
technical
feature
is
used
is
a
policy
issue
which
will
be
decided
by
other
forums
and
in
other
places.
So
you
know
we're
here
just
to
talk
about
how
to
support
searching
when
it
is
permitted,
and
it's
not
for
us
to
decide
when
and
where
it's
permitted
with.
G
B
K
K
It
can
be
a
stream
in
the
first
three
for
the
first
three,
perhaps,
and
just
an
object
in
porn
containing
information
about
any
PP
postal
address
in
the
for
the
fourth
such
pattern.
The
second
member
of
the
chosen
object
is
called
rule
is
a
string
whose
possible
values
at
those
details
in
RFC,
74
83.
K
K
K
Let
us
imagine
to
represent
a
query
like
that
find
domains
whose
registrants
email
matches
blah
blah
the
string
and
the
text
address.
Matches
Bava
as
a
postal
address
in
this
case,
having
a
compact
notation
is,
is
better
than
having
two
separate
parameters,
one
for
the
value
and
one
for
the
role.
If
we
are
convinced
that
the
research
pattern
should
be
represented
as
an
object
chosen
is
obviously
the
best
candidate
to
pass
objects
in
a
string
anyway.
Jason
contains
some
characters
that
are
invalid.
In
URL,
there
are,
according
to
my
opinion,
free
possible
solution.
K
One
is
the
you
are
URL,
encoding
and
decoding.
That
is
the
solution
adopted
by
the
specification
and
URL
encoding
and
decoding
is
performed
natively
by
web
browser
and
is
supported
by
library,
values,
program,
programming,
languages,
another
solution,
and
it
is
standard.
Another
solution
is
converting
joseph
to
be
to
binary
and
to
represent
the
binary
data
as
an
excitation,
a
string
this
is
can
be
from
the
but
binary
data
are
not
real
and
not
readable
and
not
human
readable.
K
The
first
solution
is
using
a
Johson
variation
that
complies
with
URL
specification,
but
neither
of
these
methods
standard
is
a
standard.
Next
please,
this
is
the
last
slide
is
two
points
of
discussion
about
the
research
draft.
If
the
rest
search
should
be
based
on
other
entity
properties,
different
from
email
and
form,
a
name
and
and
and
if
reverse
edge
should
be
a
standard
to
other
objects,
because
we
all
know
that
entities
are
obviously
that
that
our
relationship
with
any
other
object
inaudible.
K
L
One
quick
one
Rick
Wilhelm
for
the
record:
can
you
flip
back
to
the
beginning
slide
about
the
policy
about
the
rationale
down
so
this
one
here
in
the
middle
it
says,
requirements
from
ICANN,
next-gen,
RDS
PDP
was
terminated
by
ICANN,
because
it's
it's
been
largely
overcome
by
events
due
to
the
expedited
PDP
and
so
setting
aside.
L
So
as
far
as
motivation
for
doing
something
like
this
it,
I
wouldn't
lean
it
on
what
we've
got
here,
because
what's
going
on
in
and
around
search
as
relates
to
RDS
Registration
Data
Services
is
likely
to
become
changed
right.
So
so
this
particular
the
the
next-gen
RDS
PDP
policy
development
process
got
shut
down
a
couple
of
weeks
ago
after
and
then
things
are
up
in
the
air
with
regard
to
the
expedited
policy
development
process.
So
that's
a
that's
a
policy
point
which
is.
L
Know
and
so
now,
flip
setting
that
aside,
our
DAP
is
very
early,
so
yeah
we're
taking
that
head
off.
Our
DEP
is
very
early
in
the
game.
People
are
just
getting
started
and
there
are
DAP,
implementations
and
I.
Don't
know,
I,
don't
know
if
it's
really
wise
for
us
to
be
starting
to
standardize
this
kind
of
stuff.
L
That's
it's
going
beyond
what
our
DAP
really
when
there's
been,
when
no
one
is
using
it
in
production
in
an
anger,
yet,
additionally,
people
there's
people
that
are
under
contracts
to
provide
our
tap
services
that
are
going
to
be
bound
by
performance,
service
and
availability
service
level
agreements.
These
kind
of
things
will
burden
implementations
for
all
implementers
and
contracts
are
not
frequently
sophisticated
enough
to
be
able
to
parse
out
value-added
things
like
this.
L
Probably
we're
talking
about
here,
searching
sorting
and
all
reverser
channel
itself
from
the
base
level
service,
and
it
can
make
it
difficult
for
implementers
that
are
that
are
not
that
that
have
a
contractual
obligation
to
provide
this
stuff.
And
if
you
mess
up
an
SLA,
you
can
lose
your
contract
right.
So
I.
K
Know
that
the
first
the
first
item
of
the
icon
requirements
is
in
the
past
is
was
publishing
rather
in
the
past,
because
it
is
about
four
years
ago.
But
there
is
an
a
recent
document
about
registry
agreement.
Second
item,
and
that
suggests
the
use
suggest
implementation
of
some
kind
of
reverse
search
capability
to
to.
K
K
Especially
in
the
case
of
research,
it
can
cause
some
some
potentially
risks,
or
it
can
be
more
or
less
compliant
with
it
appear.
When
I,
when
we
we
have
thought
about
the
this
capability,
we
are
thinking
we
were
thinking
the
requirements
coming
from
dottie
registrar's
that
requiring
the
list
of
domains
related
to
an
entity,
for
example.
So,
in
our
implementation,
each
registrar's
can
search
for
its
own,
its
own
domains,
not
the
other
domains,
okay,
but
this
is
a
controlling
way,
a
control
solution.
K
B
We'll
take
the
one
more
comment
from
the
queue
here,
but
I
do
want
to
be
careful
to
not
go
too
far
down
the
path
of
trying
to
solve
a
problem
or
decide
whether
solution
is
right
or
not.
That's
for
discussion
in
work
once
we
choose
to
adopt
the
document
I'll
make
one
more
comment.
Building
a
lot
Rick
said,
but
please
go
ahead.
First,.
M
From
from
icon
technical
part,
I'm,
not
I
can't
really
talk
about
gdpr
contracts,
but
I
do
agree
that
well,
our
top
implementations
are
at
the
very
early
stage.
I
think
that
this
is
partly
because
there
isn't
specification
or
a
formal
way
yet
to
do
these
kind
of
things
and
I.
Don't
think
it's
gonna
happen
unless
we
have
at
least
the
start
of
a
standardization.
M
So
I
think
this
is
a
good
work
that
will
hopefully
push
or
make
things
go
start
moving,
and
also
aside
from
whether
it's
contracts
or
policy
or
whatever
could
be
used
as
arguments
or
motivation
for
research.
It's
also
important
thing
to
consider
that
if
this
functionality
is
implemented
for
some
registries
right
now
in
the
Whois
which
is
expected
to
be
replaced
by
our
app,
there
should
be
some
consideration
as
to
how
the
this
new
replacement
protocol
can
fulfill
the
same
test.
M
B
Thank
you.
So
speaking
as
Gerald
me
built
a
little
bit
on
on
what
Rick
said
and
and
whether
it
wardo
there
was
was
adding
to
also.
It
is
true
that,
in
a
in
a
production
way,
our
DAP
for
the
use
by
registries
for
by
domain
registries
is
relatively
early
days
and
new,
and
there's
a
lot
of
discussions
going
on
about
the
rollout
of
our
DAP
in
the
ICANN
arena,
where
it
belongs,
because
that's
a
policy
consideration
as
to
whether
or
not
you
have
to
do
it
or
not.
B
Certainly,
there
are
registries
that
have
a
need
for
being
able
to
do
searching
in
our
DAP,
and
this
says
this
is
a
carry
work
item
from
when
the
our
dap
protocol
and
specification
was
written,
searching,
was
sort
of
cut
off
and
not
addressed
in
that
base
specification.
So
this
work
item
is
actually
existed
for
a
while,
but
we
now
have
a
motivation
to
to
resurface
and
resurrect
this
work
item
and
actually
make
it
come
to
closure,
because
there
are
domain
registries
that
have
this
requirement.
That
would
like
to
solve
this
problem.
C
B
I
think
that
that's
fine,
and
so
that's
a
reason
for
it
to
be
in
this
working
group
and
that's
a
reason
for
us
to
talk
about
the
issues
that
go
with
implementing
searching.
We
will
certainly
be
influenced
by
what
I
can
is
going
to
develop
with
respect
to
gTLDs,
but
it
certainly
does
not
have
to
be
the
determining
factor
what
we
do,
given
that
this
is
early
days,
we
have
an
opportunity
to
influence
in
the
other
direction,
as
we
very
well
will
do,
because
there
is
an
are
dap
pilot
working
group.
That's
working
in.
B
K
Thank
you
for
this
and
I
yeah
you
know.
I
think
you
say
that
I
I'm
not.
I
was
not
influenced
by
the
hikin
requirements
when
I
as
submit
when
I
submitted
this.
The
first
proposal
be
because
the
the
proposal
was
before
the
action
requirements
appear
in
the
in
a
document,
so
I
was
influenced
by
the
requirements
coming
coming
from
from
don't
IP
registrar's,
but
I
think
that
there
are
common
requirements
of
other
registering
other
at
least
sensitivities,
but
and
after
a
year.
K
B
B
Documents
to
tell
us
about
not
just
two
but
I
will
put
up
these
slides
to
start
with
and
I
will
let
you
sort
out
where
we
are
okay,
with
respect
to
the
two
documents
that
are
going
on
here.
So
this
is
the
slides
here
for
login
security
policy
extension.
The
agenda
slides
are
linked
to
the
login
security
extension
itself
and
with
that
introduction,
I
will
let
you
sort
out
for
the
working
group
and
those
listening.
What's
going
on,
okay,.
C
So,
just
not
to
get
confused.
I'll
start
off
with
the
login
security
extension,
which
I
introduced
at
the
last
IETF
in
particular.
That
extension
fixes.
One
really
important
issue
in
EPP
is
the
fact
that
there
is
a
16
character,
password
limit
in
the
RFC,
so
this
particular
login
security
extension
fixes
that
allows
for
longer
passwords.
But
while
we
were
working
on
that,
we
decided
to
go
ahead
and
include
additional
features
that
we
thought
were
necessary
as
we
were
going
through
it,
so
that
particular
extension
I'm,
really
hoping
will
be
adopted
by
the
working
group.
C
That's
not
get
confused
with
this
particular
extension.
This
was
recently
published
and
you'll
notice
the
pattern
here
you
take
the
extension
you
get
policy
to
it,
and
that
is
an
extension
of
the
registry
mapping
which
defines
the
server
policies
associated
with
implementing
a
particular
extension.
In
this
case.
It's
a
login
security
extension
next
slide,
so
yeah.
So
this
is
the
first
example
of
what
we
call
a
system-level
extension
of
the
registry
mapping.
In
particular,
a
login
is
not
associated
with
zone.
A
registry
can
support
many
Teale,
these
or
zones
in
this
case.
C
It's
talking
about
how
the
login
works
and
this
particular
policy
extension
defines
the
maze
and
the
shoulds
and
the
options
that
are
defined
within
the
log
and
security
extension
and
I
have
to
say
that
I
highly
encourage
those
authors
of
EPP
extensions
to
go
through
the
exercise
of
creating
a
policy
extension.
It's
well
worth
the
time,
so
their
next
slide
please.
So
this
is
the
policy
information
included
in
this
extension.
But
first
is
the
login
password
format.
C
C
In
response,
and
in
particular,
it
includes
like
the
levels
that
will
be
supported,
whether
or
not
that
particular
security
event
has
expiry,
whether
or
not
what,
when
it
will
start
with
turning
warnings
and
what
will
happen
in
the
event
that
a
particular
item
expires.
Will
it
fail
a
connection
but
fail
to
login
will
do
nothing
at
all
and
then
there's
one
other
set
of
policy
information
here.
It's
related
statistical
security
events,
in
essence,
defining
thresholds
and
periods
for
a
stat
event.
Okay,
the
next
one,
so
I
hope
you
can
read
this
it.
C
You
guys
actually
read
that
in
the
back,
probably
not,
but
I'll
try
the
best
I
can,
in
essence,
what
this
shows
is.
It
shows
the
policy
for
the
password
itself.
In
this
case
it
shows
a
Perl
compatible,
regular
expression
for
the
format
of
the
password
and
a
simple
description
for
what
that
format
next
time.
The
next
is
includes
the
bullion
for
the
user-agent
support,
and
then
it
starts
going
through
the
list
of
security
events.
C
The
first
is
for
the
password
in
this
case
it's
describing
a
password
expiring
policy,
I'm
not
advocating
for
this
in
any
way
shape
or
form,
but
this
is
an
example
of
where
a
password
would
expire
in
90
days.
It
would
start
warning
the
client
15
days
ahead
of
expiry
and
then
it'll
specify
the
fact
that
the
logon
will
fail
if
the
password
expires.
The
next
item
is
for
certificates,
we're
talking
about
the
client
certificates.
C
In
this
case,
what
I'll
do
is
it'll
start
warning
the
client
that
their
client
certificate
will
expire
in
fifteen
fifteen
days
and
that
if
the
client
certificate
does
in
fact
expire,
the
connection
will
fail,
because
the
TLS
handshake
will
fail
next
time.
Here's
an
example
of
dealing
with
deprecating,
ciphers
and
TLS
protocols.
In
this
case,
it'll
return
back
whether
or
not
a
deprecated
site
for
a
TLS
protocol
was
negotiated.
There's
other
options
in
here.
C
C
This
is
an
example,
and
this
is
completely
fictitious
of
the
use
of
a
stat
security
event.
In
this
case,
it
can
inform
the
client
that
there's
been
a
over
a
threshold
number
of
failed
logins.
In
this
case,
within
a
day,
let's
say
that
we
got
over
a
hundred
failed
logins
from
a
client.
The
server
knows
this.
The
server
could
inform
the
client
about
this
and
they
can
set
up
a
monitor
to
see
what's
going
on,
then
we
also
have
a
custom
policy
said
next.
C
So
in
conclusion,
this
login
security
policies,
the
first
system
level
registry
map,
be
an
extension
and
it
provides
the
policies
for
implementing
the
login
security
extension
and
in
review
covers
the
login
password
format,
policy,
support
for
the
user
agent,
as
well
as
the
set
of
security
events
and
the
policies
for
each
one
of
those.
So
I
encourage
you
to
review
and
provide
feedback
on
those.
C
Actually
have
one
thing:
I'm,
not
I'm,
actually
not
requesting
for
this
particular
extension
to
be
adopted
by
the
working
group.
At
this
point,
the
registry
map
being
we're
still
working
on
the
IPR
declaration,
so
the
registry
mapping
the
launch
phase
policy
and
the
login
security
policy
extensions
will
pending
that
particular
item.
Okay,.
B
C
B
B
C
So
this
is
that
you
can
probably
just
go
to
the
next
slide.
If
you
remember
from
the
IETF
last
time,
we
had
a
working
session
on
unhandled,
namespaces
and
then
out
of
that.
What
we
came
to
agreement
with
his
effect
of
the
server
should
not
return
extensions,
not
in
the
client
login
services,
so
Martin,
Casanova
and
I
took
the
action
item
to
create
a
draft
that
provides
a
concrete
proposal
or
approach
to
solve
this
problem.
C
So
the
proposal
is
defined
within
the
unhandled
namespaces
draft,
and
in
this
case
it
chose
to
use
the
existing
ext
value
element
in
the
EPP
RFC,
and
it
includes
the
full
unhandled
xml
within
that
element.
So
go
to
next
slide,
please,
okay!
So
in
review,
the
steps
on
negotiating
the
services
include
the
server
returning
the
list
of
services
that
it
supports.
C
C
So
with
this?
If
you're
familiar
with
the
EFT
value
element
includes
two
sub
elements,
one
is
the
value
and
the
other
is
the
reason
the
value
is
marked
as
being
unprocessed
by
the
XML
parser.
So
therefore,
it
will
not
it'll
be
processed
like
a
string.
It
will
not
look
to
validate
in
the
case
of
a
reference
to
an
XML
schema
and
will
not
do
a
Dom
purse
on
it.
C
C
Well,
in
this
case,
the
PPR
RFC
already
includes
an
element
that
would
be
better
than
the
CDA.
You
can
actually
directly
put
it
in
there
yeah
and
I've
implemented
this.
It's
really
easy
to
implement.
Believe
me,
the
other
element
here
is
the
fact
that
the
full
XML
of
the
unhandled
namespace
can
be
moved
into
the
ext
value
element,
so
that
includes
both
object
level
extensions
as
well
as
command
response
extensions.
C
The
other
thing
is
the
fact
that
it's
RC
compliant
we're
not
returning
any
information
that
will
be
fully
processed
by
the
client
and
that's
is
we're
not
gonna
break
the
client.
The
other
thing
is
the
fact
that
the
client
can
process
that
information
later
and
then
probably
the
most
important
item
is
the
fact
that
it
addresses
the
poll
message
issue.
We
don't
want
to
create
a
poison
message
in
the
pool
cue
and
we
do
not
want
to
be
returning
poll
messages
that
are
not
compliant
with
the
RFC
next.
C
So
here's
an
example
I
hope
that
you
can
see
this
on
the
left.
Yes
on.
The
left
is
a
object
extension.
So
you
see
here
that
says
namespace
XML.
All
that
happens
is
that
it
morse
the
object
response
into
a
standard,
EPP
response
using
the
est
value
element.
So
it
puts
the
namespace
XML
under
the
value
sub
element
of
the
EFC
value,
and
then
it
has
a
pre
formatted
reason.
So
the
client
can
see
this
can
key
off
the
reason
and
then
see
what
data
was
unhandled.
C
Obviously,
the
client
can
go
ahead
and
support
that
particular
namespace
and
not
have
it
moved
to
this
location,
but
this
is
a
way
to
go
next
and
here's
an
example.
Let's
say
fictitiously
that
the
client
doesn't
support
the
domain
mapping,
let's
just
say
so,
there's
an
example
of
putting
the
domain
transfer
data
into
the
value
element
of
the
ext
value,
with
the
pre
formatted
reason
yeah.
C
Next
now,
in
the
case
of
command
response
extensions,
there
can
be
many
command,
responsive
stanchions,
so
any
one
that
is
not
supported
would
simply
be
moved
from
the
extension
block
into
the
EFC
value
element
you
see
here
in
the
next
slide
is
an
example
of
the
DNS
second
extension.
So
in
essence,
if
the
client
did
not
support
the
DNS
SEC
extension,
the
server
could
choose
not
to
return
it,
or
in
this
case
it
could
return
it
and
put
it
into
an
EFC
value
element
instead
of
not
returning
at
all.
Next.
C
One
important
item
is
the
fact
that
this
can
be
used
in
both
general
epp
responses,
as
well
as
whole
message
EPP
responses
in
the
case
of
general
EPP
responses,
the
sewer
really
has
a
choice
here.
The
server
could
not
return
the
information
or
then
decide
to
use
the
unhandled
namespace
approach
to
return
the
information,
and
really
this
is
only
applicable
to
command
response
extension,
since
in
essence,
if
the
server
received
a
command
for
the
object,
you
assume
that
the
client
already
supported
the
object
right.
C
An
example
here
would
be
the
RTP
RFC
if
the
client
didn't
support
it.
The
other
use
cases
for
poll
messages.
The
draft
has
a
must
in
here.
In
essence,
it
pretty
much
says
that
when
polemicist
are
inserted
by
the
server
you
don't
know
what
services
the
client
actually
will
support
when
they
consume
those
messages.
So,
in
this
scenario,
using
this
approach,
the
client
will
be
able
consume
those
messages
safely,
and
so
this
would
apply
for
both
object
level
and
command
response.
Extensions.
C
An
example
here
is
the
change
poll
extension,
which
was
actually
the
trigger
for
this
discussion
in
the
first
place.
So
next,
so
in
conclusion,
the
unhandled
namespace
is
draft,
maintains
compliance,
which
is
number
one,
enables
the
information
be
returned
unfiltered.
It
allows
for
the
poll
messages
to
be
consumed
without
craving
a
poisoned
message
scenario
and
then
allows
for
the
client
to
go
ahead
and
process
that
information
later.
H
C
We'll
put
it
this
way
when
well,
prior
to
that
working
session,
there
was
a
request
to
create
a
draft
to
be
able
to
discuss.
Originally,
we
didn't
have
a
draft.
We
had
a
discussion.
We
came
to
the
conclusion
that
the
server
should
not
return
extensions
that
are
not
supported
by
the
client
and
then
they
said
it
was
not
important
enough
in
general,
but
there
was
no
consensus
at
that
point.
That's
why
Martin
and
I
had
the
action.
I'm
gonna
go
to
create
a
concrete
approach
for
some
consideration,
so
this
is
an
example.
I.
B
H
So
the
registry
I
can
say
that
we
have
two
kinds
of
registrar's:
those,
though
that
poll
and
those
that
don't
or
we
have
a
third
kind,
that
poll,
but
just
some
way
the
messages.
So
yes
and
those
that
poll
they
will
understand
our
messages
and
those
that
don't
poll.
Well,
they
don't
poll.
So
they
don't
have
the
problem
and
yep.
H
C
You
know
I
what
I
wanted.
What
I
wanted
to
say
was
that,
since
we
had
the
first
graph
come
through,
that
was
associated
with
a
poll
message
meeting
the
change
poll
draft
and
this
issue
came
up.
In
essence,
there
was
no
good
answer
and
how
to
solve
that
problem.
I
really
didn't
have
a
good
answer.
Right
I
was
like
I,
don't
know.
I
said
we
need
to
solve
this
I
got
to
tell
you
right
now,
just
simply
returning
the
poll
messages
without
considering
what
the
client
supports.
C
H
H
Rekts
with
our
registrars
that
require
them
to
support
our
EPP
and
to
talk
ETP
to
us
and
understand
what
we
tell
them
over
EPP
and
how
they
manage
to
my
name's
over
EPP
and
basically
the
same
that
every
gTLD
has
with
I
can
probably
registrar's
have
with
their
ccTLDs
too.
And
so
you
basically
contractually
require
to
understand
that
EPP
and
well
well,.
C
This
through
policy
and
and
it's
pretty
nice
that
the
registrar's
happen
to
support
all
of
the
poll
message,
extensions
that
you
happen
to
support
and
I
hope
that
you
validate
that
they
do
that.
But
if
there's
a
case
where
they
don't
and
they
actually
login
and
don't
support
your
extension
and
that
since
you're
blindly
ignoring
it.
So
unless
you
are
actively
looking
at
what
they
are
sending
you
with
the
login
services,
I,
don't
believe
you're
gonna
be
following
the
protocol.
B
So
yeah
Jim
Galvin,
just
speaking
as
an
individual
I,
think
I'll
offer
or
it
can
in
response
I
mean
sure
we
we
have
all
of
those
same
kinds
of
registrar's,
but
the
thing
that
occurs
to
me
is
as
a
general
registry
service
provider
not
specific
to
anyone,
but
you
know
we're
not
the
only
one
around
here
who
support
a
few
hundred
of
these
things.
B
You
know
you
get
a
lot
of
mixing
and
matching
with
registrar's
and
registries
and
bad
things
happen,
and
even
if
you
were
contractually
obligated
to
support
everything,
there's
just
a
lot
of
scenarios
into
which
bad
things
can
happen
and
I.
Think
registries
taking
on
the
opportunity
to
be
well
behaved
in
as
many
circumstances
as
possible
is
a
good
thing.
So
at
least
for
us
we
would
certainly
support
this
kind
of
model
yeah,
but
this
would
be.
H
Technically
well-behaved,
but
they
wouldn't
solve
the
underlying
problem
that
now
the
registrar
has
the
information,
but
the
register
doesn't
do
anything
with
it
because
you
know
say
obviously
don't
didn't
want
the
information
in
the
first
place
or
don't
understand
it.
So
we're
just
saying
yeah
be
giving
you
something
technically
be
solving
this
problem
that
you,
but
in
the
end,
if
you
really
want
to
do
it,
you
need
to
solve
the
problem
that
you
need
to
understand
it.
So
we're
not
solving
anything,
we're
just
saying
yeah
we
making
it
look
good.
H
B
The
registry
is
not
killing
the
registrar,
there's
no
poison
message
and
you're
right,
even
if
they
ignore
it,
and
all
of
that
that's
a
good
thing,
but
I'm
not
at
risk
of
actually,
you
know,
causing
them
to
be
to
be
to
be
hit
badly
and
I.
Think
registries
should
be
well
behaved
in
that
way.
So,
okay,
one
last
comment
will
cause
the
queue
after
Mario.
K
C
This
solves
a
problem
with
the
client
does
not
understand
and
by
putting
it
under
the
value
element.
Since
its
marked
within
the
RFC
XML
schema
to
not
process
it,
it
will
not
go
through
to
try
to
find
the
XML
schema
for
it.
I've
already
implemented
this
and
it
causes
like
a
string.
It's
beautiful,
it's
very
easy
to
process.
K
A
C
B
B
Out
of
the
ICANN
Technical
Operations
Group,
it
really
just
describes
what
a
repository
could
look
like.
Ideally,
should
look
like
on
the
registry
side
so
that
registrar's
can
easily
get
and
quickly
get
access
to
various
kinds
of
reports.
That
registries
are
obligated
to
provide
to
them
as
part
of
the
gTLD
space
in
I
can
really
is
a
fairly
straightforward
document
and
very
straightforward
request
and
the
ideas
it
just
provides
the
SFTP.
You
know
what
that
should
look
like
and
the
path
to
go
down.
C
This
is
Jim,
go
from
Verisign,
actually,
I've
reviewed
this
and
reviewed
the
other
report,
drafts
and
I
kind
of
have
a
concern
on
these
ones.
I'm,
not
sure.
If
this
has
worked
for
this
working
group,
they
seem
very
particular
specific
to
you
know,
directory
structures
of
file
names
and
that
sort
of
thing,
I
think
what
would
be
more
applicable
for
this
group
would
be
like
a
report
definition,
language
mechanism-
that
is
more
generic.
That
would
allow
and
support
any
sort
of
report.
C
I'm,
not
sure
if
we,
whether
or
not
this
working
group
would
want
to
bring
up
how
to
format
a
particular
report.
This
is
the
way
I
look
at
it.
It's
like
data
escrow.
You
look
at
the
data
escrow
graphs.
They
define
a
mechanism
to
define
I,
get
escrow
and
does
not
define
the
specifics
of
any
one
data
escrow,
okay,.
B
I
B
You
know
fair
enough.
You
can
certainly
raise
the
question
of
whether
or
not
it
really
is
something
that's
appropriate
here
and
all
of
the
work
that's
in
front
of
this
working
group
often
has
the
issue
that
we're
a
fairly
small
set
of
people
that
are
looking
at
these
things
and
I
I.
Don't
have
a
good
answer
for
that,
but
you
can
certainly
raise
that
on
the
mailing
list
too,
and
we'll
see
what
kind
of
discussion
we
get
out
of
all
of
that
I'm.
Fine
with
that
I
think.
I
I
There
are
people
like
they
I
understand
what
they
are
trying
to
achieve
and
they
sort
of
one
of
their
documents.
Ground
yeah
by
taking
our
scene,
want
to
eat.
Yeah
I
believe
that
there
must
be
other
ways
we
seen
I
can
see
pH,
takeoffs
or
whatever,
to
agree
on
things
that
are
not
necessarily
need
to
go
through
the
full
ITF
process,
but
no
put
it
that
way.
That.
B
I
L
So
I
have
a
slightly
different
point
on
it
on
that
document,
is
that
it
and
I
need
to
bring
this,
and
admittedly,
I,
haven't
gotten.
This
comment
to
see
pH
tech
ops
yet,
but
that
that
document
on
reporting
nails
has
specifies
that
it's
using
SFTP,
which
we
at
least
at
our
company,
we're
not
big
fans
of,
and
so
we're
like
sideways
with
that
straight
out
of
the
gate.
So
when
it
seems
odd
to
anchor
something
like
that
in
SFTP.
But
that's
just
me
no.
J
This
Roger
and
I
think
this
is
a
good
discussion
that
we're
having
and
I
like
Jim's
idea
of
maybe
a
definition
worth
versus
specifics,
but
I
mean
this
all
started
out
of
the
fact
that
registrar's
wanted
to
well.
At
least
one
registrar
wanted
to
get
things
in
a
more
predictable
way.
J
Instead
of
you
know,
ten
years
ago,
it
was
easy
to
negotiate
with
eight
people
to
get
something
that
looks
similar
now,
it's
200
registries
that
we
have
to
work
with
to
get
something
similar
and
it's
a
lot
more
difficult
now,
and
it
was
interesting
because
our
first
response
was
hey.
Okay,
we
want
this
in
this
format
and
the
registries
returned
and
said:
well,
we've
got
200
other
registrar's
requesting
in
a
slightly
different
format.
So
can
you
agree
on
something?
So
that's
where
the
whole
standard
process
came
in
was
like.
Okay,
both
sides
were
saying
yeah.
J
It
needs
something
to
happen,
so
you
know.
Where
does
that
happen
at?
But
yes,
I
agree
that
some
of
the
technical
or
some
of
the
little
pieces
here
can
be
refined
and
to
Jim's
point.
Maybe
it
makes
sense
to
come
up
with
the
definition.
Not
necessarily
specific
things
so
definitely
something
to
look
at
Thanks,
so.
B
J
No,
this
rider
we'll
make
this
quick,
so
we
can
move
on
to
other
things,
all
right,
because
Jim
kind
of
tila
on
this
a
little
bit
earlier.
This
is
ongoing
work.
Actually,
a
lot
of
works
going
on
right
now
with
it
not
within
the
working
group.
Some
of
the
members
of
the
working
group
are
doing
it.
J
There's
the
IPR
issue
that
Jim
mentioned
earlier.
That
needs
to
get
solved
before
we
really
feel
comfortable
about
trying
to
bring
it
into
a
group
and
getting
it
work.
So
again,
I
encourage
everybody
to
go.
Look
at
this.
It
is
something
that's
moving
along
fairly
quickly,
so
anybody
needs
information
could
ask
Jim
or
myself,
and
we
can
get
more
details
to
you.
I,
don't
think
we
need
to
cover
that
right
now.
So
should.
B
Just
remind
folks
we,
there
have
actually
been
several
interim
meetings
during
which
this
design
team,
if
you
will
has
been
meeting
and
talking
about
registry
mapping,
so
there's
been
plenty
of
opportunity
to
dig
in,
and
you
know,
look
at
some
of
the
details
here
separate
from
the
IPR
issue
that
we're
trying
to
to
deal
with.
So
you
know
please
take
note
and
feel
free
to
jump
in
and
continue
to
participate.
Yeah.
J
B
B
So
that
leaves
us
with
a
little
over
15
minutes
for
what
we
had
set
aside
or
intended
to
set
aside
about
10
minutes
talking
about
working
group
adoption
and
our
milestone,
review
and
discussion.
So
let
me
kind
of
set
up
the
discussion
here.
I
had
sent
a
note
to
the
mailing
list
a
little
bit
for
reference.
There
are
currently
three
milestones
left
on
our
milestone
list,
even
that
we
have
progressed,
especially
in
the
last
nine
months.
B
We've
done
just
an
absolutely
stellar
job,
finally,
coming
to
closure
on
a
number
of
documents
that
that
have
been
hanging
on
for
a
while,
the
two
that
are
listed
here
in
boldface.
You
know
an
informational
document
or
third-party
DNS
providers
and
the
validate
mapping,
which
is
what
Roger
had
just
mentioned
for
the
extension
extensible
provisioning
protocol.
B
Those
two
really
are
the
ones
that
are
left
at
the
bottom
one.
There
is
left
in
italics
because
it
the
bundling
registration
as
I
had
reported
earlier.
We
have
a
shepherd
right
up
for
that,
and
so
it
is
very
soon
it
will
be
submitted
to
the
ihe
for
publication.
So
we
are
left
with
just
those
two
milestones.
B
So
we're
kind
of
making
a
specific
proposal
to
the
working
group,
and
this
is
for
discussion,
and
so
this
period
right
now
is
for
discussion
of
this
issue.
When
this
working
group
started,
we
had
something
over
a
dozen
documents
that
we
sort
of
automatically
adopted
and
inherited
right
away,
and
you
know,
chose
to
progress,
and
it's
kind
of
been
a
tough
slog
for
us
to
move
those
documents
along
other
working
groups
in
the
IETF
that
tend
to
have
a
lot
of
things
that
come
and
go.
B
Dns
off
is
always
my
personal
favorite,
but
there
are
other
other
working
groups
that
have
things
that
happen.
You
know
they
also
have
for
themselves
a
bit
of
process
and
some
policy
for
themselves
about
how
many
milestones
that
they
really
take
on.
How
many
documents
do
you
adopt
at
a
time,
and
otherwise
you
just
sort
of
keep
them
out
there
in
a
pen
being
state
waiting
for
an
opportunity
to
slot
them.
B
B
But
I
think
we've
got
five
is
a
good
starting
number,
but
it
is
open
for
discussion.
Nonetheless.
A
second
question,
of
course,
is
as
I
was
looking
at
those
two
milestones
that
are
up
there.
It
does
beg
the
question
of
whether
those
things
are
actually
going
to
come
to
closure
or
not.
The
validate
document
has
really
had
no
real
discussion
or
or
progress
in
quite
a
long
time,
although
rider
did
just
bring
it
up.
So
you
know.
Maybe
it
is
something
we
do
want
to
latch
on
to
now
and
move
along.
B
The
DNS
operator
document
is
kind
of
interesting.
It
has
sort
of
come
and
gone
over
the
years
that
this
working
group,
and
even
previously
the
EPP
working
group
under
which
it
started
that
document
existed.
The
document
editors
have
had
their
own
personal
issues
and
they
kind
of
come
and
gone,
but
it's
not
clear
what
the
status
of
that
document
is
and
whether
or
not
it's
even
something
that
could
progress.
So
I
actually
do
believe
that
it's
fair
for
this
working
group
to
consider.
B
Think
because
if
we
have
login
security
and
policy
at
seven
documents
but
in
any
case,
a
critical
question,
whatever
number
we
choose
with
the
answer
to
question
one,
a
critical
question
then,
is
going
to
become
well,
since
we
have
seven
to
choose
from
which
seven
get
to
fill
the
three
open
slots
or
four.
If
we
decide
not
to
keep
the
other
document
so
the
way
in
which
I
would
suggest
that
we'll
do
this
on.
B
The
mailing
list
will
come
up
with
some
way
to
give
everyone
a
chance
to
vote
for
their
document
or
to
submit
an
ordered
list
of
their
preferred
documents
to
advance.
And
then
the
chairs
will
collate
that
and-
and
you
know,
create
a
summary
and
put
that
back
onto
the
mailing
list
for
yet
one
more
cycle
with
the
working
group
in
case
people
want
to
change
their
mind
based
on
what
comes
out
of
that.
I
do
want
to
make
sure
that
we
give.
B
You
know
all
opportunity
for
voices
to
be
heard
about
documents
and
not
trying
to
rush
it
too
quickly,
but
it
is
an
important
consideration.
You
know
how
many
should
we
have
and
then,
given
that
it's
not
going
to
be
all
seven
all
at
the
same
time,
how
are
we
going
to
select
which
ones,
and
so
this
is
an
opportunity
for
some
open
discussion
about
this
process.
E
Thanks
Jim
Scott,
Holland,
bye
I
do
have
some
concerns
about
a
fixed
number,
but
inevitably
something
else.
Pops
up
that's
important
right
and
okay
and
I've
got
my
own
selfish
reason
and
selfish
concern
for
bringing
this
up.
I've
got
an
internet
draft
out
there
that
describes
a
federated
authentication
approach
for
our
DAP.
That
I
have
not
brought
to
the
working
group
for
adoption
yet
because
I
can
still
doesn't
have
his
policy
act
together
and
I
don't
want
to
be.
E
You
know
coming
up
with
protocol
for
policy
that
is
TBB
because
I
don't
know
if
I
can
meet
those
requirements,
but
let's
just
imagine
that
we
live
in
some
fantasy
world
and
eventually
I
can
get
its
policy
act
together.
Well,
the
next
thing
I'm
going
to
want
to
do
is
bring
that
document
to
the
working
group
and
say:
hey.
Would
you
please
consider
this,
and
if
we
have
a
limit
of
five
and
we're
already
at
five
and
I've
got
a
backlog
of
five
more?
E
That
document
may
end
up
sitting
for
quite
some
time,
so
as
I
guess:
I'm,
okay,
with
the
limit.
As
long
as
we
do
have,
some
recognition
of
there
may
be
a
need
for
an
exception
process,
and
you
know
whatever
those
exceptional
considerations
may
be,
that
the
working
group
would
consider
expanding
beyond
five.
If
a
case
can
be
made,
you
know
for
the
need
to
take
on
one
or
two
more
or
whatever.
J
Roger
similar,
but
not
quite
the
same
I
I,
think
that
the
the
numbers
a
good
goal
to
keep
in
mind
some
documents
will
seem
like
there's
a
lot
of
work
on
them
and
it'll.
Take
a
lot
of
effort,
so
I
again,
I'm,
not
sure
that
five
as
a
static
number
makes
sense
as
a
goal
to
me.
It
makes
sense
and
actually
I
I
think
it
probably
is
closer
to
four
with
the
amount
of
people
that
actually
do
the
work
on
the
list.
J
For
so
as
a
lot
of
work
for
each
person,
that's
actually
doing
work,
so
I
would
suggest
four
as
a
goal,
but
this
guy's
point.
Yes,
we
need
to
be
able
to
examine
and
prioritize
and
get
things
on
and
off
the
list
if
needed.
So
as
far
as
which
ones
of
the
two
leagues
current
ones,
I
would
I
would
tend
to
agree
that
the
DNS
seems
to
have
fallen
off
I'd
like
to
hear
from
some
of
the
author's
current
authors.
J
I
know
that
they
were
in
discussions
of
using
other
so,
but
it
would
be
good
to
hear
from
them
see
if
it's
needed.
The
validate
I
would
like
to
get
pushed
through.
We
do
have
a
couple
people
that
have
started
implementations
on
them,
so
I
would
like
to
continue
that
and
finish
it
through
for
those
people.
So
thank
you,
okay.
Thank
you.
N
E
C
This
Jim
goal
from
Verisign
yeah
I
am
I,
second,
that
the
fixed
or
yes,
third,
the
fixed
limit
is
it's.
The
fact
that
there
are
different
drafts
have
a
different
amount
of
work
associated
with
them.
If
you
consider
like
the
launch
phase
draft
at
eventually
Parc
and
registry
fee,
those
require
a
lot
of
work,
and
so
some
of
these
may
not
be
that
controversial.
It
may
be
pretty
easy
to
push
through.
Some
of
the
other
ones
will
take
a
lot
of
work.
I
think
like
what
stream
mapping
in
particular
would
be
a
lot
of
work.
J
B
I'm
not
seeing
anyone
in
the
meet
echo
queue.
Let
me
just
offer
some
observations,
I
guess,
speaking
as
chair
about
all
of
this
and
haven't
coordinated
this
with
Antoine
in
particular.
I
do
understand
the
need
for
an
exception
process
and
and
I
would
I
would
think
that
our
area
director
would
be
sensitive.
To
that
you
know,
I
mean
if
we
could
make
a
good
case,
then
you
know
we
could
certainly
deal
with
issues
that
come
up.
B
The
only
observation
that
I
would
make
in
this
space
is
I
think
that
if
there
are,
if
we
are
actively
working
on
whatever
number
of
documents,
it
is
and
we're
gonna
take
on
another
one.
That's
an
interesting
thing
for
us
to
be
thinking
about,
I
mean,
as
Roger
was
just
saying,
there's
a
limited
number
of
us
anyway.
It
just
feels
like
odds,
are
something's
gonna
get
swapped
out.
If
we're
gonna
try
to
swap
something
in
so
you
know,
maybe
the
exception
situation
is.
Is
you
don't
necessarily
put
something
in
you
know?
B
You
don't
take
it
off
of
the
active
list,
but
you
recognize
as
an
operational
action
that
it's
gonna
fall
to
the
lower
list
and
fall
lower
in
priority
and
you're
going
to
focus
on
something
new
that
you
want
to
add.
And
then
then
the
concern
is
going
to
be
I'm
sure
with
our
area
director
that
we
manage
the
number
of
exceptions
that
we
had
that
come
along
before
we
actually
unload
something.
We
have
to
be
a
little
more
deliberate
about
unloading,
something
you
can't
just
Park
it.
B
You
know
and
know
that
you're
parking
it
we're
gonna
have
to
make
this
dance
and
and
even
with
respect,
to
open
ID
I
understand
Scott
sensation.
But
the
interesting
observation
I
make
is
that
for
those
of
us
who
really
do
care
about
that,
we're
already
in
both
communities
and
we're
doing
it
in
both
places
anyway,
so
you
know
putting
it
here,
we're
sort
of
we
know.
B
We.
We
only
did
the
reporting
repo
document
here,
but
there's
a
there's
another
reporting
document
out
there
that
probably
ought
to
be
brought
here
and
yeah
and
and
there's
the
data
escrow
documents
which
are
not
on
the
list
here,
but
they've
been
kind
of
pending
for
a
while
too.
So
we
we
have
a
number
of
documents
that
are
kind
of
important.
They
are
important
because
you
know
the
ICANN
community
is
going
through
a
transition
on
the
gTLD
side,
and
so
there
are
a
number
of
open
issues
that
are
really
a
work
in
progress.
B
B
I
think
that
we'll
probably
try
one
more
time
to
open
this
discussion
and
press
on
that
on
the
mailing
list
and
see
what
folks
said:
I
actually
like
Ryder's
suggestion
about
going
down
to
for
I,
think
making
it
four
is
probably
the
right
number,
especially
if
we
have
the
option
for
an
exception
list
and
the
ability
to
add
things.
I
think
you
know
so
that
five
is
sort
of
what
I
had
in
my
mind,
but
if
we
make
it
four
as
sort
of
the
real
action
ones,
that
actually
does
give
us
a
slot.
B
C
B
C
B
So
those
two
actions
that
come
out
of
this
one
action
is
to
just
press
on
this
discussion
on
the
mailing
list.
I,
we
had
published
these
three
questions
on
the
mailing
list
of
you
a
couple
of
weeks
ago.
There
were
only
two
messages:
I
think
that
went
to
the
list
about
it.
So
I
want
to
press
on
that
again,
but
I
I
suspect
that
there
won't
be
too
much
discussion
and
then
we'll
quickly
decide
on
a
number.
Unless
I
mean
anyone
wants
to
object,
strongly
I.
Think
I'm
as
chair
gonna
push
on
four.
B
B
It
has
sort
of
been
languishing
on
and
off,
so
we'll
press
on
that
to
see
if
we
have
four
slots
available
or
well
three
slots
available
or
two
on
our
list
and
then
the
third
action
will
be
for
the
chairs
to
make
a
consolidated
list
of
all
the
documents
that
are
available
and
eligible
for
adoption
and
then
will
first
do
a
little
iteration
to
make
sure
we've
got
them
all,
and
then
we
will
conduct
a
a
some
kind
of
voting
mechanism.
So
a
forethought
fourth
action
for
that
for
the
minute
taker.
B
B
They
got
real
buckle
action.
One
is
to
restart
the
questions
to
the
working
group.
Action
two
is
to
reach
out
on
the
list
to
the
dns
operator.
Folks,
action
three
will
be
to
create
a
consolidated
list
of
documents
that
are
eligible
for
adoption,
so
that
we're
clear
on
what
we're
looking
at
a
complete
set,
and
then
action
for
coming
out
of
this
will
be
to
actually
conduct
a
vote
of
some
sort.
We'll
conduct
some
kind
of
consensus
poll
on
how
to
choose
those
documents.
B
O
A
B
E
Hollenbeck,
just
a
quick
reminder:
I
sent
a
note
off
to
the
list
earlier
we're
going
to
be
having
a
registration
operations
workshop
in
conjunction
with
ICANN's
GDD
summit,
interesting
enough
right
back
here
in
Bangkok,
I
think
it's
in
May.
So
if
you
are
going
to
be
at
the
GDD
summit
and
you're
looking
for
some
interesting
things
to
talk
about
with
respect
to
this
from
an
operational
perspective,
please
plan
on
being
there
please
consider
developing
a
presentation
proposal.