►
From YouTube: IETF114-REGEXT-20220728-2130
Description
REGEXT meeting session at IETF114
2022/07/28 2130
https://datatracker.ietf.org/meeting/114/proceedings/
A
All
right
so
welcome
everyone.
Thank
you
so
much
for
coming
to
the
registration
protocols,
extensions
working
group
very
glad
to
have
you
here.
We
have
our
co-chairs
both
present
here
at
this
meeting,
I'm
sitting
at
the
table,
I'm
jim
galvin
and
antoine
versuren.
You
can
see
the
giant
head
on
the
screen
over
there
on
the
other
side,
so
thanks
everyone.
We
we
only
have
an
hour
today.
A
We
do
have
a
a
couple
of
discussion
topics,
one
which
might
be
a
little
bit
lengthy,
but
we'll
just
jump
through
our
details
here.
So,
let's
see,
let's
just
move
forward
one
in
the
slides.
This
is
the
standard
note.
Well,
everyone
should
be
very
well
familiar
with
it
by
now.
Even
if
you're
a
newcomer,
you
surely
have
been
to
a
meeting
before
this
one,
so
I
won't
really
belabor.
This
point
also
just
a
reminder.
We
now
have
a
whole
set
of
code
of
conduct,
guidelines
and
a
reminder.
A
You
know
treating
each
other
with
respect
and
speaking
slowly
and
limit
the
use
of
slang
a
couple
of
important
things
to
put
up
there,
but
also
like
to
take
this
opportunity
to
remind
people
that
everything
is
recorded
here.
Make
sure
that
you're
aware
of
that
and
keep
that
in
mind
when,
when
you're
speaking
it
to
participate
in
the
room,
you
can
use
the
qr
code,
which
is
not
on
the
screen
anymore.
But
I
believe
it's
on
the
back
of
a
couple
of
chairs.
A
You
surely
know
all
of
that
by
now,
and
in
any
case
you
can
go
to
the
agenda
the
the
full
agenda
page
and
for
each
individual
meeting.
There
is
an
icon
over
there
on
the
right
on
the
line
for
choosing
to
join
the
meeting
room.
You
must
join
the
meeting
room,
at
least
at
the
local
tool,
to
speak,
please
so
that
you
can
properly
get
yourself
in
the
queue
put
your
hand
up
and
we'll
call
on
people
to
come
up
to
the
mic.
A
And
yes,
the
important
thing
about
signing
into
the
room
is,
of
course
it's
the
blue
sheet
reference
and
that's
where
all
of
that
comes
from.
So
thanks
for
that,
and
last
point
here
is
masks
are
required.
Unless
you
are
speaking
at
the
microphone
and,
strictly
speaking,
I
guess
I
can
wear
mine
it's
supposed
to
work
just
fine,
even
at
these
mics
right
people
have
had
some
issues
at
the
mics
in
the
center
of
the
room.
So
the
reminder
is
to
please
make
sure
to
get
very
close
to
the
microphone.
A
Please
do
eat
the
microphone
and
you
know
speak
in
a
normal
or
slightly
above
voice,
so
that
your
sound
can
carry
into
the
room
properly
all
right
thanks
very
much,
and
I
can
see
that
everyone
in
this
room
has
a
mask
on
and
we
appreciate
that
all
right.
Here's
our
agenda
for
today
it's
a
pretty
pro
forma
agenda.
A
What
we
normally
do
so
we'll
just
kind
of
zip
through
some
things
here,
pretty
quickly,
we've
kind
of
already
been
into
the
welcome
and
introductions
and
we've
covered.
The
note
well
just
a
reminder
in
general
that
we
very
much
like
we're
trying
very
hard
to
move
forward
with
document
management
and
reviewers.
You
know
we.
A
A
A
So
let's
move
to
a
look
at
the
documents
we've
published
since
the
last
time.
Sadly,
none,
but
I
expect
a
banner
year
to
be
coming
up
as
we
move
along
here.
We
have
quite
a
few
documents
that
are
very
close
to
the
end
and
we
also
have
moving
along
here.
We
have
a
document
in
particular
one
that
is
currently
with
the
iesg.
A
A
So
that's
much
appreciated
by
the
rest
of
the
ietf.
We've
certainly
had
the
folks
who
are
much
more
expert
in
internationalization
issues
who
paid
a
lot
of
attention
to
this.
I
think
it's
in
a
pretty
good
place,
I'm
not
going
to
walk
through
all
of
the
issues
that
have
been
discussed,
but
thank
you
to
the
document
authors
and
the
document
shepherd.
A
You
know,
who've
been
carefully
tracking
all
of
these
things
and
making
sure
that
all
the
details
are
covered
and
I
believe
the
document
is
getting
very
close
to
being
released
from
the
iesg
that
all
the
issues
have
been.
I
think
all
the
issues
have
actually
been
acknowledged
at
this
point
and
taken
care
of,
so
I
expect
the
isg
will
do
its
final
due
diligence
and
that'll
move
along
into
the
rfc
editor
queue.
So
that's
a
good
thing,
no
material
issues
that
had
to
be
handed
back
to
us
to
address
so
yay
for
us.
A
C
So
here
they
are
again,
and
I
think
this
is
where
we
were
going
right-
and
you
can
all
hear
me
so
this
one
you
already
did:
okay,
existing
work,
no
presentations
well,
the
first
one,
of
course,
is
a
simple
registration
reporting.
It's
still
in
our
queue,
so
I
think
the
chair
rule,
but
jim
do
you
want?
Do
you
have
anything
to
say
about
your
document.
A
No
thanks
to
jim
gould,
who
provided
some
detailed
comments.
We've
provided
a
revised
document
and
we're
just
frankly
kind
of
holding
back
at
the
moment,
because
there
are
other
documents
that
are
kind
of
in
front
of
it,
rather
than
pressing
on
getting
it
published,
but
no
new,
significant
updates
at
the
moment,
and
we
expect
that
we'll
move
that
along
as
soon
as
something
else
moves
up
into
the
queue.
First,
thanks.
C
E
D
All
right,
so
we've
been
slowly
updating
this
draft
and
the
the
main
feedback
we've
received.
There's
sort
of
two
two
camps
here.
One
is
there's
some
folks
that
have
an
ongoing
concern
that
the
draft
will
drive
policy,
which
is
which
is
not
what
it's
intended
to
do,
but
there
is
a
concern
that
it
will
just
by
its
existence.
D
D
So
what
we
were
thinking
is
you
know
with
this
draft.
This
is
you
know
if
you're
going
to
do
something
if
you're
going
to
be
using
terms
and
the
ietf
is
where
you
take
that
to
say:
here's
how
you
do
it,
but
we're
really
not
trying
to
set
the
policy
here.
So
I'm
looking
for
feedback
as
to
is
there
any
language
that
we
can
add.
That
would
relieve
some
of
that
concern,
I'm
proposing
to
add
some
additional
text
to
the
introduction
and
abstract
being
very
explicit
that
this
is
not
intended
to
promote
policy
development.
D
F
G
G
F
Can
I
can
I
offer
two
comments,
as
as,
as
you
noted,
icann
frequently
refers
to
rfcs
as
a
source
to
draw
from
in
their
definitions.
This
is
intended
to
be
exactly
in
that
line.
It's
the.
The
awkwardness
that
I
think
you're
implicitly
talking
about
is
that
these
definitions
had
not
existed
in
rfc
form
before
I
can
start
putting
these
into
contracts.
F
C
G
G
So
so,
thanks
for
that
steve,
I
appreciate
the
the
feedback
thing
comment.
It's
precisely
the
variability
of
that
of
the
dictionary
and
the
fact
that
it's
going
to
be
starting
to
be
leaned
on
by
contracts.
That
makes
it
unsuitable,
because
the
contracted
parties
can't
have
the
definition
of
what
a
registration
is
be
open
for
interpretation
by
an
expert
group.
The
the
contracts
need
firm
language
upon
which
to
be
built
and
having
the
these
kind
of
definitions
that
are
contractually
important,
be
rested
in
an
rfc,
that's
open
to
malleability
by
an
expert
group.
G
No
matter
how
expert
they
are
is
not
the
kind
of
contractual
certainty
that
contracted
parties
can
live
with,
and
so,
while
I
understand
that,
it's
that
it
may
be
interesting
and
useful
for
a
population
of
certain
groups,
a
key
constituency
in
this
whole
thing
are
the
icann
contracted
parties,
and
this
makes
their
lives
their
contractual
lives
much
more
difficult
than
the
benefit
that
it
gives.
I
would
offer.
Thank
you.
F
F
D
F
F
C
C
G
G
We
are
very
careful
about
which
urls
we
use
so
as
the
urls
that
go
into
the
contracts
are
the
actual
firm
urls
that
the
urls
can't
be
variable
in
later
spots
that
we
nail
down
the
actual
reference
urls
with
the
text
that
they
can't
later
refer
to
something
else.
So
the
contracted
parties
contracts
are
serious
business,
they
incorporate
and
reference
rfcs
for
very
important
things,
because
the
ietf
makes
important
contributions
to
those
things.
G
Their
firmness
and
their
quality
is
important,
and
when
we've
got
something
like
this,
it's
a
data
dictionary
that
could
be
moving
underneath
that
could
be
incorporated
in
the
future.
It
sets
a
bad
situation
up
for
the
icann
contracted
parties,
precisely
because
the
itf
rfcs
have
such
standing.
So
it's
not
to
denigrate
the
rfcs.
It's
direct,
I'm
pointing
out
the
fact
that
they
carry
a
lot
of
weight
in
the
icann
community.
Thank
you.
F
Yeah
yeah,
but
the
the
the
point
is
exactly
to
nail
these
down
and
put
them
in
a
a
solid
position,
we're
talking
about
an
iana
managed
registry
that
is
intended
to
be
to
have
exactly
this
solidity
that
you're
talking
about
and
not
be
mangled
or
changed
arbitrarily
over
time.
It's
the
same
as
any
other
protocol
definitions.
You
need
them
to
be
quite
stable,.
H
Can
I
george
michaelson
apnea?
Can
I
talk
briefly
to
this?
I
I
actually
have
a
great
deal
of
sympathy
to
the
problem.
A
contracted
party
would
have
in
this
space
and
I
don't
think
your
response
from
pir
is
silly
in
any
sense
at
all.
I
think
this
is
a
rational
response,
but
I
wanted
to
observe
the
nature
of
an
rfc.
H
Is
the
post
publication?
They
are
substantively
immutable
and
were
there
subsequent
change
to
a
data
dictionary,
we
might
call
it
a
9999
biz
process
in
draft,
but
when
it's
published,
the
number
it
gets
will
not
be
99.99,
it
can't
be.
The
nature
of
the
document
is
that
it
becomes
an
immutable
state
of
the
data
dictionary
at
the
time
it
is
published,
but
your
substantive
point
about
the
contractual
and
legal
issues.
I
think
that's
a
genuine
concern.
H
F
Thank
you,
george
very
well
stated,
and
it
reminds
me
of
since
I
invented
the
rfcs
50
years
ago,
as
genuinely
requests
for
comments.
I've
observed
that
we
passed
the
1984
mark
of
george
orwell
and
that
the
words
don't
mean
anything
like
what
they
used
to
mean
requests
comments
are
no
longer
requested.
C
Okay,
thank
you,
steve,
and
I
want
to
say
the
record.
Well.
My
remark
was
not
so
more
about
that.
Perhaps
steve
you
might
be
able
to
explain
what
the
the
experts
are
supposed
to
do.
Are
they
going
to
change
any
of
the
definitions
that
are
in
the
data
dictionary,
or
do
you
envision
that
they
are?
You
know
reviewing
new
additions
for
new
terms
that
need
to
go
into
the
data
dictionary.
C
C
C
Okay,
so
that
was
extreme
decision
and
then
we
come
to.
I
think
the
major
part
of
our
discussion
here
today
will
be
about
the
art
up
extensions
and
identifier
conformance.
As
most
of
you
seen.
There
has
been
quite
some
discussion
on
the
mailing
list
recently
about
this
topic.
Firstly,
I
want
to
follow.
I
apologize
for
not
entering
the
discussion
immediately.
I
had
a
pretty
long
vacation,
so
I
had
to
read
it
all
back
and
it
was
quite
a
lot
and
I
think
many
people
have
had
the
same
issues.
C
A
So
what
we're
gonna
do
here
is
I'm
gonna
very
briefly,
just
kind
of
look
at
a
summary
of
the
discussion
that
happened.
I'm
sure
that
most
of
you
have
already
looked
at
the
slides
here.
So
you
know
what
the
punchline
is.
I
think
the
most
important
thing
to
say
is
that
we're
not
really
going
to
try
to
review
the
technical
merits
of
any
one
of
the
proposals
or
another,
so
we're
going
to
come
at
this
from
a
slightly
different
direction.
A
Look
again
a
bit
at
the
problem
that
we
think
we're
trying
to
solve
here
and
we're
going
to
put
a
proposal
forward.
So
this
is
just
a
a
chairs
proposal,
for
you
know
how
to
proceed
and
and
where
to
go
from
here
and
so
we'd
like
to
focus
the
discussion
on
our
proposal,
not
on
the
technical
merits
of
one
option
or
another
and
the
path
forward.
A
So
with
that
in
mind,
this
slide
really
is.
I
I
owe
thanks
to
jazip
zing,
who
actually
produced
a
document,
a
multi-page
document
where
he
did
quite
the
technical
analysis,
a
summary
of
all
of
the
issues.
I
want
to
thank
him
for
that.
I
just
kind
of
picked
out
a
few
things
here,
just
to
put
it
in
for
the
historical
record
so
that
we
can
all
see
what's
there
again.
A
I
really
don't
want
to
dwell
on
on
the
various
technical
merits
of
these
different
things,
except
to
say
that,
frankly,
there
really
isn't
anything
wrong
with
any
one
of
them.
You
know
if
we
were
starting
from
scratch.
I
think
that
all
three
of
these
are
perfectly
valid
paths
forward
and
and
we'd
be
having
a
slightly
different
discussion.
A
We'd
want
to
dig
in
a
little
more
on
on
the
technical
merits
of
the
differences
between
these
things,
so
that
we
could
think
more
about
what
our
future
looks
like
from
today,
as
opposed
to
what
was
done.
You
know
when
epp
was
created
and
looking
forward
and
how
it
put
things
out
there.
So
our
particular
choice
here
and
the
proposal
that
we're
going
to
get
to
is
not
intended
to
undermine
any
one
of
these
options.
A
I
think
they're
they're
all
good
choices,
they
all
have
their
advantages
disadvantages,
but
you
know
we're
just
gonna
we're
gonna
move
on
from
that
at
the
moment.
Okay,
you
know,
and
clearly
the
other
thing
to
keep
in
mind.
Is
that
we're
a
relatively
small
group,
really
those
who
are
very
active
in
these
discussions
really
are
all
experts,
and
so
the
opinions
about
each
of
these
individual
options
are
very
solid
and
stable
opinions.
You
know
I
mean
these
are
people
who,
who
really
you
know,
do
command
the
respect
that
they've.
H
A
In
presenting
these
options
and
talking
about
them,
but
as
chairs
the
problem
that
we're
faced
is
we
don't
have
consensus,
which
is
kind
of
interesting
in
our
group,
consensus
usually
means
just
finding
three
to
five
solid
people
who
are
not
an
author
of
the
document
or
or
otherwise
engaged
with
its
movement
who
agree
or
don't.
You
know
at
least
explicitly,
don't
have
any
objection
to
it
and
we
don't
even
have
that.
It's
clear
that
we
we've
got.
You
know
the
people
who
we
would
normally
turn
to
to
help
steer.
A
The
group
in
a
single
direction
are
all
on
on
different
sides
of
this.
So
on
the
one
hand
you
know
what
we
have
here
is
is
a
technical
problem,
but
we
have
an
internet
standard
that
has
a
defined
solution
for
what
we're
doing,
we
can,
certainly,
you
know,
have
some
discussion
about
how
clearly
defined
all
of
that
was,
but
what
the
chairs
are
putting
forward
here
is
given
that
we
have
an
internet
standard,
we
really
do
have
to
fall
back
on
on
the
process.
A
Point
of
there's
a
pretty
high
bar
for
changing
what
already
exists
there
has
to
be,
by
definition,
that's
what
it
means
to
be
an
internet
standard.
So
you
know
with
respect
to
these
options.
We
we,
you
know,
got
to
thinking
about
okay.
Well,
if
that's
the
case,
then
you
know
what
do
these
things
look
like
against
the
standard?
That's
already
there
and
we
took
a
step
back
to
ask
ourselves.
You
know
what
problem
are
we
really
trying
to
solve?
A
I
want
to
call
out
a
couple
of
specific
sections
which
have
appeared
on
the
mailing
list.
I
believe
scott
has
scott
hollenbeck
called
out
both
of
these
sections
as
part
of
the
discussion,
but
in
any
case
you
know
in
the
rdap
rfcs
the
first
one
in
the
series,
in
the
extensions
does
in
talk
about
the
fact
that
the
rdap
identifier
itself,
I'm
sorry.
A
The
extension
identifier
for
rdap
in
the
registry
should
be
unique
against
all
other
identifiers
and
so
that
that
becomes
in
our
mind
as
we
we
look
at
how
to
think
about
these
things.
The
critical
characteristic
that
we're
looking
for
in
defining
extensions
in
any
extension
in
in
our
dap
and
another
thing
is
in
1983,
which
is
the
response
specification
which
talks
about
responses.
Look
like
it
also
explicitly
talks
about
what
goes
in
the
rdap
conformance
is
a
unique
string.
That's
a
literal
value
in
the
rdap
extension
registry.
A
A
What's
your
metric
for
evaluation
of
some
of
these
changes,
a
lot
of
the
discussion
we've
noticed
focuses
on
programming
as
a
metric,
for
you
know,
which
which
option
to
choose
some
things,
you
know
require
more
programming,
work
than
other
things,
taking
a
step
back
and-
and
maybe
this
is
just
our
point
of
view-
but
it's
certainly
I'll
say
for
myself.
It
represents
my
experience
over
time.
A
In
the
ietf
you
know,
programming
is
not
really
the
first
order
metric,
that's
not
to
say
that
complexity
is
not
important,
but
what
we
really
care
about
is
protocol,
behavior
and
protocol
performance.
I
mean
to
a
large
extent.
Programming
is
a
one-off
thing
right
once
you
figure
out
what
you
want
to
do
you
put
whatever
effort
you
have
to
into
the
programming,
and
then
you
move
on.
A
So
you
know
judging
a
particular
option
based
on
the
amount
of
effort
to
get
it
right,
doesn't
feel
like
the
right
metric,
you're,
really
more
concerned
with
how
it's
all
going
to
behave
and
how
it
comes
together.
So,
in
the
end,
what
we
think
is
you
know,
have
we
created
a
problem?
Is
there
a
problem
out
there
that
does
something
different
in
terms
of
the
first
principles
of
uniqueness
and
optionality,
we
think
that
extensions
in
general
have
to
have
those
two
characteristics.
A
A
A
Focusing
on
the
fact
that
we
want
to
keep
the
uniqueness
and
optionality,
and
we
also
think
that
simplicity
is
preferred,
then
the
observation
we
make
is
these
discussions
about.
The
options
are
about
finding
some
way
to
version
extensions
and
supporting
a
versioning
option
of
some
sort
in
the
extensions,
and
it
is
our
belief
here
and
our
assertion
that
support
for
versioning
is
not
an
integral
part
of
the
base
standard.
It's
not
part
of
our
dap
as
defined,
and
while
it
might
be
interesting
to
solve
that
problem.
A
As
part
of
you
know
our
working
group
here,
we
honestly
have
not
heard
we
don't
believe
any
of
the
options
have
motivated
the
need
for
changing
that
particular
characteristic.
Focusing
on
uniqueness
and
optionality.
Versioning
is
not
part
of
those
two
things,
it's
a
different
thing
entirely
and
that
wasn't
covered
in
the
base
back.
It's
just
not
present
and
not
intended
to
be
there.
A
Now
we
do
observe
that
certainly
you
could
choose
to
provide
optioning
inside
of
your
extension
definition
if
you're
so
inclined,
arguably
option
three
in
that
list
is
kind
of
like
that
option.
Three
is
essentially
describing
a
mechanism
whereby
an
extension
itself
could
decide
in
its
own
specification
to
provide
a
means
for
versioning.
That
would
be
fine.
You
know,
I
mean
that's
an
independent
object.
A
So
I
think
that
you
know
what
we're
proposing
is
probably
closest
to
option
one,
but
in
principle
you
know
we
just
want
to
focus
on
the
fact
that
none
of
these
options-
really
you
know
they
haven't
made-
they
haven't
motivated
a
change
to
a
full
internet
standard,
and
so
we
believe
that
versioning
is
not
something
that's
covered
and
we
should
not
open
that
door
and
open
that
topic
in
this
in
this
working
group.
At
this
time
that
trying
to
challenge
the
base
specification,
doesn't
we
haven't
got
consensus
to
do
that?
A
Not
at
all
there's
been
no
technical
motivation
for
for
doing
that.
So
that
is
our
response
to
all
of
that.
Discussion,
not
sure
how
that's
gonna
going
to
sit
with
people
give
people
a
chance
to
think
about
that
a
bit
more
I've
added
a
little
bit
of
color.
Oh,
we
do
have
someone
in
the
queue
here.
So
let's
take
that
question.
So
jim
gould
go
ahead.
A
E
Can
okay
good?
Thank
you.
Well,
first
off
I
I
wanted
to
say
I
I
appreciate
the
passionate
debate
on
the
list.
It's
I
really
enjoyed
it
and
I
want
to
appreciate
the
the
work
that
the
chairs
did
in
coming
up
with
this
proposal.
I
know
it's
difficult
and
I
can
get
behind
it.
I
do
have
a
couple
caveats
that
I
want
to
point
out
that
I
I
really
believe
that
version
is
an
important
element
that
we
should
look
to
add
in
the
future
in
some
way.
E
So
that
may
be
something
for
us
to
look
for
the
opportunity
to
do
so.
The
other
is
that
we
do
need
to
support
versioning
of
policy
identifiers,
for
example,
the
pro
the
the
rdap
profile
identifiers
version
and
those
scenarios
are
important.
There
are
not
extensions
with
actual
elements
of
of
an
extension,
so
I
want
to
ensure
that
that
version
can
continue
to
be
supported
in
the
extension
register.
G
A
Even
on
this
slide,
the
second
bullet
under
the
second
bullet,
where
you
make
the
observation
that
you
know
there
probably
is
an
opportunity
for
additional
clarity
regarding
versioning,
I
put
it
there
on
the
slide
when
antoine
and
I
were
talking
and
left
it
as
kind
of
a
question
mark,
because
whereas
the
change
of
the
lunar
neck
level,
zero
to
just
lunarnic,
really
isn't
a
rada
change
and
that's
a
fairly
straightforward
and
easy
thing
to
do-
it's
not
clear
that
this
is
a
straightforward
and
easy
thing
to
do
so.
Jim.
A
You
just
brought
up
the
issue
that
versioning
is
something
that
we
should
approach
and-
and
you
know,
pay
more
attention
to
and
bring
it
as
a
topic
forward,
and
certainly
don't
object
to
that.
I
agree
it's
it's
a
very
it's
certainly
a
technical
topic
within
the
context
and
within
scope
for
this
working
group.
So
you
know
there's
an
opportunity
there.
If
someone
wants
to
press
on
that
and
have
that
discussion-
and
it
is
related
to
this
question-
you
know-
should
we
have
some
additional
clarity
regarding
versioning,
I
don't
know
I
I
was.
A
We
were
looking
anton
and
I
trying
to
decide
if
there
was
an
editorial
point
somewhere
along
the
way
where
we
could
add
some
changes.
That
might
make
this
a
little
more
clear,
but
it
just
started
getting
really
kind
of
uncertain.
I
felt
like
we
were
crossing
a
line
between
editorial
and
material
and
figured.
It
was
really
a
question
to
bring
back
to
the
group.
Here
I
mean,
if
there's
interest,
I
think
I'd
I'd
like
to
see
us
do
that
as
a
working
group,
but
I
don't
want
to.
A
B
Sure,
thank
you,
jim
scott,
holland
back
here.
First
I'd
like
to
say
I
do
support
this
proposal.
I
it's
it's
actually
something
a
suggestion
I
made
on
the
list
several
weeks
ago,
basically
be
kevin.
I
because
I
I
agree
with
your
assessment
that
there
are
some
places
in
1983,
where
the
wording
is
a
little
inconsistent.
You've
got
the
one
example
there,
where
there's
one
example
that
talks
about
the
string
lunar
nick
being
used
as
an
identifier.
B
B
B
I
think
that
word
hint
is
a
little
bit
soft
and
potentially
leads
to
questions
of
interpretation
and
confusion,
and
so
I've
got
a
sentence
in
mind
that
I'm
thinking
about
that
I'll,
probably
throw
out
to
the
list-
or
you
know
in
the
creation
of
an
erotum
report
for
this,
so
we
will
have
something
to
discuss
on
list
in
terms
of
the
way
the
erotic
is
processed
and
so
for
people
yeah.
If
you're
wondering
well,
how
is
that
processed?
B
Someone?
Actually,
you
know,
goes
to
the
rfc
editor
webpage
and
fills
out
a
little
report.
Saying
hey.
I
think
I
have
found
a
technical
issue
with
this
rfc
right.
They
describe
it
in
detail
and
then
that
report
is
sent,
among
other
places,
to
the
working
group
mailing
list,
where
the
suggestion
for
the
correction,
you
know,
and
the
merits
of
that
can
be
discussed.
B
So
you
know
this
isn't
just
a
slam
dunk,
you
know
one
person
says
something
and
then
the
rfc
editor
is
noting
a
change
someplace.
We
will
still
have
an
opportunity
for
discussion
and,
as
I
said,
I
think
you
know
changing
that
word
hint
to
something.
A
little
bit
stronger
and
less
open
to
interpretation
is
one
other
place
where
we
should
probably
look
at
1983.
A
So
thank
you
for
that.
Let
me
first
say
that
I
certainly
take
your
friendly
amendment
of
reversing
my
suggested
errata
thing
here.
That's
fine!
You
know
I.
I
think
that
it
is
important
to
make
the
examples
consistent
and
your
suggestion
about
the
hint
mechanism.
Well,
I
see
antoine
came
in
the
queue
here,
there's
a
discussion
that
he
and
I
were
having
as
we
got
into
all
of
this
about
rdap
conformance,
I'm
sure
he's
going
to
ask
that
question.
So
why
don't
you
go
ahead
and
do
that.
C
C
B
Now,
unfortunately,
that's
as
far
as
it
goes,
which
means
there's
an
awful
lot
of
room
there
to
interpret
well.
What
exactly
does
extension
identification
look
like,
but
I
think
that
that
does
mean
we
have.
I
don't
know
if
I'd
want
to
call
it
a
foundation,
but
at
least
we
have
a
rough
idea
of
where
we
might
look
for
a
possible
method
and
a
mechanism
to
add
these
kinds
of
capabilities
to
our
dap.
So.
A
Before
you
before,
you
sit
down
and
step
away,
the
question
that
I
thought
antoine
was
going
to
ask:
is
he
and
I
got
into
this
discussion
about?
Why
does
rdap
conformance
even
exist
because
it
doesn't
seem
to
have
there's
no
there's,
no
material
processing
requirement
on
the
part
of
a
response
or
a
client,
and
so
it
the
only
real
purpose
that
it
had
as
far
as
we
could
tell
was
about
the
help,
because
in
in
principle
the
suggestion
is
that
all
of
the
extension
identifiers
in
use
or
supported
would
be
listed
there.
A
So
that's
its
only
real
existence,
but
it's
interesting
that
all
the
examples
say
that
rdap
conformance
must
exist
right,
but
there's
nothing
that
says
what
you're
supposed
to
do
with
whatever's
in
there
and
then,
as
you
just
said,
you've
got
the
hint
question
right,
so
it
all
just
came
to
that
larger
question.
Do
you
want
to
comment
at
all
on
that
or.
B
B
They
are
intended
to
tell
a
client
that
hey
here
is,
for
example,
a
data
structure
that
does
not
exist
in
the
core
spec
and
you
can
match
the
prefix
on
this
data
structure
to
the
identifiers
that
returned
in
the
rdap
conformance
section.
To
tell
you
where
the
specification
for
how
to
process
that
extension
exists.
A
A
I
don't
yeah,
I'm,
maybe
I'm
not
expressing
myself.
Well,
that's
not
getting
to
the
question
I'm
asking
as
as
I
understand
it,
even
when
the
when
the
server
provides
the
response,
it
doesn't
have
to
tell
you
what
extensions
that
he
used
because
that's
an
option
and
so
and
in
fact
a
client
can
simply
ignore
objects.
It
doesn't
recognize
right,
an
extension
that
doesn't
recognize
so
the
presence
of
rdap
conformance.
A
A
A
Oh,
it
exists,
so
a
client
can
know
which
career
parameters
to
use
when
sending
the
requests.
Well
sure
that
makes
sense
to
me
andy
in
in
the
sense
that
a
client
would
do
a
help
request
to
find
out
what's
available,
and
then
it
could
go
do
things
then
it
would
know
what
to
do
so.
I
do
understand
the
idea
that
the
in
the
help
response
the
the
r
adapter
performance
would
list
all
the
extensions.
A
E
Can
you
hear
me
yep
great?
Thank
you
very
much
all
right,
it's
unusual
for
me
to
be
patient,
so
yeah.
I
just
want
to
ensure
that
we
don't
disallow
a
version
of
the
policy
identifiers.
That's
all
so,
as
I
understand
it,
that
version
is
not
a
feature
of
art
app
and
that
the
registrations
of
extension
and
the
structure
of
those
extensions
will
not
include
version
or
don't
have
to.
But
as
long
as
we
also
are
don't
disallow
the
inclusion
of
a
versioned
policy
identifier,
I
think
I'm
fine.
B
There
go
ahead
thanks,
rick
scott
holland,
back
yeah,
jim.
I
agree
with
you
completely
right.
I
mean
we
already
have
registered
identifiers
in
the
iana
registry,
for
example
the
rdap
profile
that
was
developed
by
icann,
and
there
is
nothing
that
that
modifies
in
the
context
of
changing
data
structures
and
response
right.
It's
all
about
what
a
server
does
in
terms
of
constructing
the
response
within
the
confines
of
standard
95
already
right,
so
it
tells
the
client
hey.
This
is
kind
of
what
you
can
expect.
B
You
know
in
terms
of
your
response
and
how
it's
constructed,
but,
as
I
said
you
know,
nothing
was
extended.
It's
really
a
more
more
of
a
processing
oriented
thing,
and
yes,
I
want
to
make
sure
that
we
continue
to
allow
that
for
very
important
reasons
that
this
this
is
definitely
needed
from
a
policy
perspective.
A
A
H
A
Thank
you,
george
for
reminding
me
that
I
should
be
a
little
more
careful
about
that
very
good.
Yes,
we
certainly
want
to
make
sure
in
in
the
minutes
that
all
this
is
captured
and
we
should
close
out
the
discussion.
There
are
multiple
threads
on
the
mailing
list
should
try
and
pull
all
of
them
together
with
it
with
a
closing
message
which
points
to
this
discussion
and
these
slides
and
what
we're
gonna
do.
A
So,
that's
where
we'll
end
up.
Okay,
any
other
comments
or
questions
about
this,
not
seeing
anything
else
in
the
room
here.
Let
me
just
take
a
quick
look
through
the
chat
here
at
the
end.
Thank
you
andy
that
hint
was
bad
language.
Yes,
I
think
they're
just
a
couple
of
interesting
things.
It's
amazing
what
turns
up
as
one
goes
through
this
process
over
the
years,
and
thank
you
for
supporting
the
proposal.
C
A
I'll
just
comment
in
general,
I
mean,
as
antoine
had
said
in
the
beginning
there
there
are
several
documents
which
people
were
holding
back
because
they
wanted
to
make
sure
that
we
resolved
this
question
of
these
things,
and
so
we're
hopeful
that
all
of
those
are
going
to
move
along
here.
Quite
smartly,
there's
a
couple
of
them
that
we
really
do
want
and
need
going
forward
and
george.
You
know
you
should
be
raising
your
hand
in
the
queue
really
yeah
yeah
screw
the
queue
so.
H
A
Thank
you,
george.
I
know
that.
I
certainly
appreciate
that.
I
see
antoine
nodding
too.
It
was
tough
for
us.
We,
he
and
I
had
a
several
hours
of
conversation
trying
to
figure
out
where
to
take
this
and
what
to
do
with
it.
So
thank
you
for
that.
It
certainly
was
a
difficult
topic
and
difficult
thing
to
do
so,
but
yeah
so
just
a
an
outreach
to
the
authors
of
those
other
four
documents.
You
know
please
do
take
this
opportunity
to
make
sure
that
you
are
aligned
with
all
of
this.
A
I
I
think
a
couple
of
them
have
a
little
bit
of
wording,
changes
editorial
work
to
do
and
then,
let's
move
them
along.
I
think
I'm
most
interested
in
the
rdap
in
the
redacted
document
would
like
to
see
that
one
move
along
very
quickly.
That's
just
a
personal
observation,
but
there
are
quite
a
number
of
them.
People
should
push
them
out
as
quick
as
they
can
jim
gould
go
ahead.
Please.
E
B
Thank
you,
guys,
scott
holland
back
again
so
yeah
just
bringing
the
proposal
conversation
to
closure
antoine.
If
I
heard
I
think
I
heard
you
correctly,
one
of
you
will
send
a
note
to
the
list.
Yes,
just
echoing
what
george
had
said
say,
hey
look.
This
is
what
we
discussed
in
the
room.
This
is
the
proposal
and
the
idea
would
be
that
working
group
members
would,
you
know,
comment
on
the
proposal
at
this
point
right
so
right.
B
The
idea
would
be
that
will
give
you
an
opportunity
to
measure
the
consensus
of
of
our
approach
to
the
proposal.
Okay,
so
jumping
ahead,
just
a
little
bit.
If
we
do
agree
that
we
have
consensus
on
adopting
that
proposal,
I
will
volunteer
to
craft
the
errata
report
for
1983
all
right,
but
I
will
wait
until
we
I
get
to
go
ahead
from
you
that,
yes,
we
have
consensus
on
this
approach.
B
B
C
We
were
when
we
were
discussing
this.
We
saw
that
you
know
the
extension
identifier
for
lunonic
is
in
rlc's
7480,
section
8.1,
and
so
that's
where
we
thought
all
the
confusion
came
from.
You
know:
there's
one
rfc
that
talks
about
lunamic
as
an
extension
and
there's
another
irc
that
says
lunatic
level
zero
as
an
extension
but
okay,
thank
you!
No
you're
right.
We
will
draft
a
a
conclusion
for
this
discussion.