►
From YouTube: IETF111-GENDISPATCH-20210728-1900
Description
GENDISPATCH meeting session at IETF111
2021/07/28 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
Okay,
great
thanks
to
our
volunteers
in
the
in
the
chat
for
taking
the
minutes
dominique
and
john.
If
anyone
else
wants
to
head
over
the
links
in
the
chat,
so
you
can
embellish
and
add
to
the
detail
as
you
as
you
think.
A
B
B
B
B
So
make
sure
your
video
is
turned
off
unless
you're
presenting
during
the
session
or
you
come
to
the
microphone.
Save
some
bandwidth
for
everybody
else.
Do
mute
your
microphone
unless
you're
speaking
when
you
unmute
do
give
it
a
second
or
two
there's
a
short
delay
before
the
microphone
starts.
Working
use
a
headset.
If
you
can,
it
will
stop
a
lot
of
echoing
problems
that
we've
had
in
the
past.
The
blue
sheets
are
automatically
generated,
so
don't
worry
about
that
we're
taking
care
of
it
by
using
the
participation
list.
B
There
is
a
chat
room.
If
you
take
a
look
at
your
icons
above,
you
can
get
to
the
chat
room
and
you
can
detach
it
into
a
separate
window
if
you
want,
and
if
you
need
more
information,
there's
a
couple
of
links
there
for
the
participation
guide
and
how
to
report
issues
next
slide
and
here's
a
bunch
of
links
for
our
meet
echo
room.
These
were
in
the
agenda
as
well.
B
So,
let's
remember
the
process
for
this
working
group.
We
recommend
ingen
dispatch
next
steps
for
new
work
that
is
brought
to
us.
We
do
not
adopt
drafts
in
this
working
group.
We
don't
work
on
things.
We
will
have
preliminary
discussion
to
figure
out
how
to
dispatch
them,
but
not
beyond
that.
The
possible
outcomes
range
from
directing
work
to
an
existing
working
group
or
proposing
forming
a
new
working
group.
B
We
can
recommend
ad
sponsorship
assuming
an
ad
is
willing,
and
we
can
also
recommend
additional
discussion
or
other
development
as
required,
or
we
can
decide
that
the
ietf
should
not
work
on
this
topic.
This
is
all
output
that
goes
to
our
dutiful
ad,
who
is
also
the
ietf
chair
and,
of
course,
lars
gets
to
decide
what
to
do
with
our
input
next
slide.
B
Please
try
and
state
your
name.
We
can
tell
who's
speaking
usually
from
the
participant
list,
but
if
we're
not
looking,
it's
helpful
for
people
to
hear
it.
Please
do
try
and
keep
the
dispatch
question
in
mind
when
you're
making
comments,
we
can
talk
about
the
logistics
of
any
particular
proposal,
but
do
try
and
point
that
discussion
toward
and
therefore
I
think
this
should
be
dealt
with
in
this
particular
way
by
the
working
group
and
try
and
keep
your
comments
as
short
as
you
can.
B
There
is
a
join
the
cue
button,
which
is
the
little
hand
raised
thing,
but
that
just
puts
you
in
the
list
of
the
queue,
so
we
can
keep
track
of
you
in
order
to
start
speaking,
you
have
to
unmute
and
if
you
would
like
to
show
your
video
on
mute,
your
video
as
well-
and
you
can
take
yourself
out
of
the
queue
as
soon
as
you
start
speaking,
or
we
can
just
zap
you
out
of
there.
If
you
forget
to
do
that
next,.
B
So
here's
our
agenda
for
the
day
we
have
this
bit,
which
we
are
doing
right
now,
suresh
is
going
to
present
updated
work
that
he's
done
on
the
new
tax
relations
between
rfcs.
B
Then
lars
is
going
to
talk
to
the
proposals
that
he
mentioned
on
the
list
regarding
updates
for
bcp
45
regarding
the
ietf
list
kirstie's
going
to
take
over
and
talk
about
the
working
group
status
and
what
we
might
do
with
regard
to
updates
to
our
charter,
if
needed,
or
the
work
that
we're
doing,
and
then
we'll
have
some
time
for
all
other
business
and
conclusions
by
the
chairs.
It
should
any
be
necessary
next
slide.
C
Hi
yeah,
I
don't
want
to
bash
the
agenda,
but
I
want
to
mention
something,
and
that
is
we're
looking
for
more
volunteers,
for
the
iatf
sergeant
at
arms
team,
which
is
the
group
that
moderates
the
itf
discussion
list.
So
if
somebody
who
happens
to
be
in
this
virtual
room
is
interested
in
that
role,
please
send
me
an
email
or
if
you
want
to
nominate
something
else,
somebody
else
you
can
also
do
that.
Maybe
ask
them
first,
that
would
be
nice,
so
that
was
my
little
bash.
Thank
you.
B
Righty
and
alex
alexander.
B
Dispatch
is
for
applications,
layer,
stuff,
gen,
dispatches
processes
and
policy
stuff
all
right.
Thank
you.
No,
no
worries
anything
else
with
regard
to
the
agenda
today,.
B
E
E
So
this
shaft
is
like
pretty,
I
would
say,
like
hanging
around
for
a
little
bit
so
miria
and
I
used
to
be
on
the
iesg
and
we
did
see
like
quite
a
few
documents
coming
through.
Like
you
know,
we
discussed
a
lot
about
like
whether
it
should
update
some
older
documents
or
not
and
like
you
know,
when
it's
missing
something,
should
it
be
updating
some
document
or
not
right
and
one
of
the
things
we
studied,
like
you
said:
okay,
like
the
usage
of
updates
itself,
is
like
very
unclear.
E
So
what
does
update
really
mean
is
like
unclear,
so
we
kind
of
saw
three
different
kind
of
meanings
ascribed
to
updates
right
and
we
came
up
with
a
few
tags
like
tag
definition
so
like
these
are
not
like.
Something
we
are
set
on
is
something
to
specify
the
different
meanings
of
the
updates
relationship.
E
One
of
them
yeah,
is
that,
like
you
know,
it's
some
kind
of
bug
fix
or
like
some
changes
to
the
rfc
that
need
to
be
implemented
by
anybody
who's.
Looking
at
the
original
rc,
that's
like
what
we
called
by
called
amends
or
amended
by
relationship
and
the
second
one
is
you
take
like
either
an
extension
point
in
the
rfc
or
some
flags
in
there
or
like
describe
some
optional
behaviors
that
are
relevant,
but
not
absolutely
necessary
for
the
for
an
implementer
of
the
original
rfc
to
do
so.
E
Those
are
the
ones
we
call
extension
extended
by
and
finally,
there's
like
a
rules,
relationship
there's
like
related
rfcs,
but
they
don't
really
update
each
other,
but
it
could
be
of
interest
for
somebody
to
check
it
out.
Right,
like
let's
say,
for
example,
we
are
up,
let's
say
like
obsoleting,
a
crypto
protocol.
It
would
be
interesting
for
somebody
to
go
and
look
at
and
say,
hey
like.
E
Why
was
this
thing
obsolete,
right
or
made
historic,
so
that
could
be
like
something
which
could
be
a
very,
very
loose
relationship
and
we
can
kind
of
hand
out
like
candy,
like
to
kind
of
put
in
like
labels
to
like
put
together
related
rfcs
of
interest
to
people,
and
so
this
is
like
one
important
thing
is
like
this
is
like
something
that
brian
brought
up
early
in
this
document.
Stuff
is
the
tags
like
you
know.
We
have
the
new
tag
right,
updates
tag
in
the
rfc.
That's
the
new
rfc!
E
That's
getting
done,
but
like
there's
also
like
a
updated
by
putting
into
an
existing
rfc.
So
it's
like
more
like
a
metadata
on
the
rfc
rather
than
part
of
the
rfc
itself.
Next
slide.
E
E
We
knew
it
was
more
than
one
or
two
right
like,
but
the
thing
is
like.
I
promise
to
go
back
and
read
like
a
bunch
of
rfcs
and
to
put
together
some
numbers
for
this,
so
this
took
took
me
a
while,
probably
like,
outside
close
to
a
year
to
get
through
this
thing.
Right,
like
you
know,
I
would
say
about
like
20
minutes
per
hour,
see
it's
like
about
80
to
90
hours
of
work.
E
To
get
this
done,
and
so
like
my
goal,
was
to
originally
do
this
for
a
thousand
rfcs,
but
at
500,
like
I
thought
like
there
was
like
a
serious
amount
of
work
done
already
and
to
kind
of
give
us
a
picture
of
how
things
are
going
to
look
okay,
so
this
is
done
for
rfc
8000
to
8500.
E
Those
are
the
ones
like
we
studied
and
the
out
of
these
there
were
95
rfcs
that
updated
other
rfcs,
and
this
is
the
updating
rfcs
and
these
95
rfcs
updated
163
other
rfcs
right-
and
this
is
because,
like
one
rfc
ended
up
updating
like
multiple
rfcs
in
a
lot
of
cases
and
the
maximum
one
I've
seen
was
like
13
rfcs,
getting
updated
by
one
next
slide.
E
So
so
just
looking
at
the
usages.
E
So,
like
you
know,
it
requires,
like,
I
would
say,
a
pretty
tight
reading
of
the
rfcs
to
figure
out
the
intent
right
and
and
that's
kind
of
one
of
the
symptoms
we're
trying
to
address
like
you
know
if
somebody
like
I've
done
like
quite
a
few
implementations
of
idf
rfcs,
I've
written
a
few-
and
it's
like
always
not
obvious,
like
from
reading
the
abstract
or
like
going
first
in
like
what
exactly
is
meant
there,
and
so,
if
somebody
sees
an
updated
byte
tag
on
an
rfc.
E
Is
this
of
interest
for
them
to
like
go
and
figure
this
out
themselves
every
time
right?
So
the
real
question
you're
trying
to
answer,
is
if
you're,
an
implementer
trying
to
implement
an
rfc
and
you
see
an
updated
buy.
Is
that
mandatory
for
you
to
do
it
or
not
right?
E
That's
the
question
we're
trying
to
answer
and
if
you
start
looking
at
it,
the
split
is
pretty
even
so
like
the
sum
of
the
rfcs
are
amendments
like
which
either
do
changes
of
intention
or
like
correction
of
errors
in
the
rfc,
so
they
absolutely
have
to
be
implemented
and
then
there's
another
percentage
of
it,
which
is
really
extensions
right
where,
like
the
you
know,
there's
additional
new
messages,
getting
defined
new
flags
getting
defined
or
new
behaviors
getting
defined
which
are
optional,
but
it
provides
some
value
add
so
you
would.
E
You
would
still
want
to
look
at
them
if,
but
it's
not
really
mandatory
to
do,
and
in
this
both
case
like
there's,
some
rfcs
that
do
both
dimension
extends
behaviors,
but
it's
towards
different
rc.
So
if
I
have
like
you
know
for
an
rfc,
that's
doing
like
six
or
seven
updates
right,
like
some
of
them
fall
into
the
exchange
camp
and
some
of
them
fall
into
the
immense
camp
right
and
like
so.
E
The
ideas
like
the
rfc,
even
within
a
given
rfc,
the
usage
of
updates,
is
like
kind
of
spread
over
the
place
next
slide,
and
so
the
other
thing
we
just
not
totally
surprising
right,
like
you
know
like,
is
there
like
some,
I
would
say
casually
related
rfcs
right
like
that,
could
fall
under
the
sea
also
so,
but
there's
only
four
of
them.
E
That
kind
of
even
fit
the
bill,
and
it's
not
surprising
because,
like
we
apply
the
update
stack
pretty
conservatively
in
the
idea,
so
the
the
working
groups,
the
chairs
the
80s
they
all
kind
of,
like
you
know,
discuss
this
a
lot
to
see
if
updates
fits
the
bill.
So
I
think
to
find
whether
this
is
going
to
get
used.
It's
probably
going
to
require
looking
at
the
non-updating
rfcs
to
see
if
the
c
also
could
have
been
used.
E
But
it's
like
a
much
larger
effort
and
to
see,
but
it's
probably
very
low
hanging
fruit
here
to
just
make
it
available
and
see
if
it
gets
used
for
people
to
start
labeling
things
as
related
next
slide.
E
Thanks
media,
would
you
like
to
also
come
up
to
the
stage
if
you're
there.
F
F
It
took
so
much
time
to
look
into
all
this
and
we
have
a
few
open
questions,
so
I
did
add
some
text
in
the
last
version
of
the
document
to
talk
about
what
are
the
risks
of
this
failing,
and
I
like
at
least
my
assessment
or
our
assessment-
is
that
there's
like
very
low
risk
to
actually
make
the
situation
worse
so
hopefully
like
this
helps
or
we
have
the
same
confusion
as
before,
and
it
didn't
help,
but
I
don't
think
it
will
make
it
worse
and
as
such,
I'm
still
proposing
that
we
go
for
pcp
and
if
we
do
that,
we
can
remove
that
text
again.
F
But
there's
some
discussion
in
there
right
now
to
reflect
what
was
discussed
on
the
list
and
then
there
are
two
more
smaller
open
questions.
So
this
document
is
also
currently
focused
to
only
address
the
ietf
stream.
I
guess,
if
other
streams
want
to
take
up
the
same
thing,
we
can
include
that,
but
it's
very
it's
focused
on
the
itf
stream.
F
So
this
is
why
we
want
to
go
through
the
itf
process
and
get
itf
consensus
about
it
and
there's
also,
we
added
a
little
bit
discussion
about
updating
or
amending
and
extending
things
cross
area,
but
we
don't
give
any
quick,
strict
rules
about
that.
So
that
was
done.
That
was
updates
was
also
used,
cross
area
before
and
really
similar
as
any
other
document.
When
you
update
something,
you
really
have
to
make
sure
that
the
content
consensus
process
of
that
stream
is
followed
in
some
way.
F
So
it's
just
a
little
bit
of
discussion,
no
strict
guidance
there
and
then
the
question
came
up.
Who
finally
decides
to
add
these
tags
and
we
didn't
any
add
any
additional
text
about
this,
but
I
think
it's
the
same
as
for
any
other
decision
about
rfcs,
it's
really
the
working
group
and
the
isg
at
the
very
end,
to
get
consensus
about
the
whole
process,
and
this
includes
the
text.
So
I
don't
think
any
additional
text
is
needed.
A
Thank
you,
okay,
thank
you
for
the
presentation.
So
with
that
we
open
up
the
queue,
as
pete
said
at
start,
just
click
the
little
hand
icon
to
join
the
queue,
and
please
remember,
to
state
your
name
at
the
mic
as
well,
so
any
opinions
you've
got
on
next
steps
for
the
work
or
dispatching
outcomes
or
clarifying
questions.
Okay,
so
john,
your
first.
G
Really
was
gonna
go
first
cuz.
I
was
curious
about
what
he
was
gonna
say,
but
one
several
quick
reactions.
The
first
is
if
this
is
done
at
all,
it's
going
to
be
very
hard
to
go
back
without
creating
even
more
confusion
than
we
have
now
so,
regardless
of
how
we
handle
it.
Procedurally,
if
this
is
going
to
be
done,
we've
got
to
take
that
seriously,
rather
than
as
a
easily
reversible
experiment.
G
The
second
observation
is
that
all
of
the
forward
forward-pointing
materials
which
have
been
mentioned
as
updated
by
and
so
on,
are
metadata
rather
than
what's
going
to
be
out
of
students,
and
that
creates
an
alternative
to
this,
which
I
hope,
we're
also
thinking
about
about
supplementing
the
existing
the
existing
updates
to
egg
with
additional
information,
rather
than
replacing
it,
which
is
a
fairly
dramatic
operation,
not
necessarily
bad,
but
especially
since
I
don't
think
you
see
any
going
back
fairly
dramatic
and
the
third
kind
of
literally
occurs
to
me.
G
Is
that
our
biggest
problem
over,
in
addition
to
comedy
in
the
chat
about
the
particular
sample
of
of
rfcs,
I
think
we
looked
at
for
the
technical
rfcs,
which
I
am
much
more
concerned
about,
that
about
the
feature
once
it's
not
clear
that
the
data
sample
is
indicative
and
more
important.
What
has
been
the
biggest
problem?
G
I've
seen
over
the
years
is
not
merely
the
update
tag
and
what
it
means,
but
the
failure
to
incorporate
materials
into
the
new
document
which
explicitly
indicate
what's
being
changed,
and
why,
and
sometimes
the
isp
is
trying
to
ask
the
ralph.
What
does
the
isg
hasn't
and
occasionally
that
material
has
been
an
internet
drafts
and
the
isg
has
taken
it
out.
G
E
Thanks
very
much
thanks
sean
if
you
can
stick
around
right
like
there's
like
two
things
like
you
said,
and
I
I
totally
agree
with
one
of
them
right
like
so.
The
the
tags
can
be
additive
instead
of
like
replacements,
and
that
was
something
we
kicked
around
in
the
earlier
idea.
Some
people
thought
that
having
the
updates
around
might
be
confusing,
but
that's
certainly
something
we
can
keep
the
updates
and
probably
add
a
duplicate,
amends
are
amended
by
tag
right.
That's
something
at
least
that
some
we
can
reverse
like
you
said.
E
If
things
go
really
wrong,
we
can
reverse
it.
So
that's
like
a
really
good
point
and
we'll
just
like
it
was
in
the
earlier
versions
of
the
draft,
we'll
just
put
it
back
in
just
as
an
option
still
for
the
second
one
right.
The
key
thing
is
like
the
the
new
rfc
can
save.
However,
it
can
be
as
clear
as
it
wants
right.
Imagine
right,
like
you
could
say,
like
hey:
these
are
the
things
you
need
to
do.
E
These
are
the
things
you
need
to
change,
but
really
what
we
are
lacking
is
a
signal
for
somebody
who
sees
35
days
like
I
know
you
know
822
right
like
I
was
doing
this
rfc
three
one
point
right
and
there's
like
so
many
updates
there.
If
somebody's
implementing,
8,
22
or
28
22
right,
they
need
to
figure
out
what
are
the
things
that
are
mandatory
for
them
to
change
and
what
are
the
things
are
optional
for
them,
some
extensible
behaviors.
E
G
But
again
speaking
strictly
about
technology,
that's
exactly
the
other
point
I
was
trying
to
make,
which
is
no
matter
what
you
do
about
categories,
that
kind
of
information
about.
What's
changed,
why
it's
changed?
What
the
effects
are,
how
significant
that
change
is.
G
F
So
I
I'd
slightly
like
to
disagree
with
you,
because
I
I
agree
to
the
fact
that
having
more
clarification
about
what
is
updated
is
important
and
the
document
does
talk
a
little
we'll
give
like
a
little
bit
more
guidance
about
this
as
well.
But
I
think
the
texts
are
even
more
important
because
I
know
a
lot
of
people
who
look
at
an
rfc
and
there's
like
a
huge
amount
of
of
updated
rfcs
right
and
they
stop
right
there
and
having
this
classified
into
different
subsets
helps
them
a
lot.
F
E
G
G
The
key
issue
there
is
looking
at
what
all
the
relationships
are.
Those
relationships
are
historically,
not
linear,
they're,
terribly
intertwined.
It's
complicated,
though
what
should
be
implemented.
What
should
not
be
implicated,
but
that
brings
us
back
not
to
the
tagging
problem,
but
to
the
old
new
track
problem
about
how
we
express
what
the
real
standard
is
for
so
and
so,
when
we've
got
a
scattered
collection
of
intertwined
documents
flowing
around
and
that's
of
course,
at
the
risk
of
re-singing,
a
very
old
song.
That's
the
new
track
problem.
A
G
Mine
yeah,
if
you
have
a
view
that
there's
that
this
needs
some
more
work,
and
we
should
probably
be
thinking
about
it
much
more
broadly
and
in
terms
of
whether
the
isg
should
be
making
additional
rules
about
what
it
mean,
what
you
have
to
put
into
a
document
if
any
of
these
update-ish
tags
apply,
and
that,
if
we're
really
circling
back
around
to
the
problem
of
helping
a
leader
understand
what
the
real
standard
is
in
a
particular
area
in
terms
of
what
we
expect
to
do,
let's
address
that
problem
head
on
and
reopen
the
set
of
questions
or
show
the
new
track
book.
G
Okay,
thank
you
for
all
the
take
and
suresh
pointed
out
those
all
potentially
in
addition
to
these
proposals,
but
if
we're
going
to
view
them.
In
addition,
it
makes
an
even
stronger
argument
for
adding
more
metadata,
rather
than
making
the
almost
irreversible
decision
of
replacing
that
chad.
Okay.
Thank
you.
H
Wrong
button,
video,
that's
the
one
I
wanted
hi.
This
is
barry
lieber,
a
bit
of
background
that
that
suresh
didn't
give
this
discussion
started.
While
I
was
on
the
iasg
and
with
miria
and
suresh,
it
came
out
of
the
realization
that
that,
very
often
when,
when
a
draft
that
we
were
going
through,
the
process
of
approving,
said
updates
this
other
draft.
There
was
some
ads
questioned
whether
updates
was
appropriate
or
not.
H
If
we
have
no
consensus
of
what
it
means,
because
it
means
multiple
things.
Maybe
the
right
answer
is
to
split
out
those
multiple
things
and
make
it
clearer.
So
in
that
sense,
I
fully
support
this
document.
I
think
I
mean
I
certainly
agree
with
john
that,
in
addition
to
this,
we
need
clear
guidance
that
you
have
to
say
what
it
is
that
you're
updating
when
you're
doing
updates
in
the
pros
of
the
document.
H
H
That's
my
preference
for
the
dispatch
answer,
but
it
seems
that
there's
enough
controversy
about
this
over
time,
as
as
we've
seen
in
the
various
discussions
that
we
might
need
a
working
group
for
it,
either
way
that
we
go.
I
think
it's
important
enough
to
do
this
document
or
something
related
to
it,
that
we
that
we
should
go
ahead
with
it
in
one
one
of
those
means,
and
I,
as
I'll
repeat,
I
hope
we
can
do
it
with
an
ad-sponsored
document
and
not
a
working
group.
A
Thanks
barry,
thank
you.
Barry
mark
you're
next.
I
Good
morning,
tomorrow,
okay
morning,
good
morning,
okay,
so
mary
and
trish,
thank
you
for
the
obviously
large
amount
of
work
over
a
fair
amount
of
time.
You've
put
into
this
we've
been
talking
about
this
for
a
little
while
now.
I
think
it
demonstrates
that
very
well
that
there
is
a
lot
of
confusion
around
the
semantics
of
this
metadata
and
and
so
I'm
not
sure
that
adding
more
metadata
is
the
right
solution
just
because
it
might
add
it
might
end
up
in
more
confusion.
I
I
I
think
that
people
authors
are
demonstrating
an
inability
to
to
conform
to
what
we
have
already.
Also,
I
think
you
know
you
look
at
a
men's
to
me.
That's
the
semantics
of
updates
extends
arguably.
This
is
why
we
have
registries
and
see
also
everybody.
This
is
why
we
have
references
so-
and
I
think
others
have
made
similar
arguments
on
the
list,
but
but
you
know
to
get
to
the
dis
patch
question,
I
very
strongly
believe
the
itf
stream
can't
and
shouldn't
create
consensus
for
document
metadata.
I
These
are
things
that
are
actually
in
the
xml
for
version
three
to
me,
that
is
very,
very
clearly
a
sign
that
the
process
that
we
are
slowly
coming
up
with
in
the
rfc
np.
Whatever
that
working
groupish
thing
is,
I
hate
the
name,
that's
the
appropriate
place
for
it,
and
so
I
think
the
dispatch
question
here
is
extremely
crystal
clear.
We
wait
for
that
to
eventuate
a
a
group
to
discuss
this
in
and
then
take
it
there
to
do
so.
F
Yeah,
thank
you
yeah.
Let
me
just
say
one
thing,
so
it's
not
an
uncommon
practice
that
one
stream
decides
to
to
implement
a
certain
practice,
or
even
these
kind
of
things,
and
because
different
streams
have
different
needs
right
and
it's
then
the
previous
rfc
editors
tasks
to
actually
figure
out.
If
this
is
useful
for
other
streams
as
well
and
then
maybe
adopt
it
or
not,
and
we
did
reach
out
to
other
streams.
So
it's
not
like
we
got
any
concerns
from
other
streams.
F
I
It's
not
a
process
concern,
it's
a
concern
that
we
we
have
expertise
around
publishing.
You
know
part
of
the
the
the
importance
one
important
part
of
the
discussion
here
is
how
the
metadata
will
be
used
and
how
it
will
be
presented,
and
that
is
deeply
tied
into
the
document
format
and
in
the
rfc,
editor,
toolset
and
and
those
discussions
happening
there.
I
think,
would
give
us
a
much
better
chance
of
success
as
well
as
coordination
across
the
streams.
E
So
one
thing
is
that,
like
we've,
been
kind
of
rc
right,
like
to
kind
of
be
in
place,
right
like
that
was
like
one
of
the
original
suggestion
is
to
wait
for
like
a
permanent
rse
and
the
editorial
stream
to
get
established
and
and
so
on,
right
like
it's
something
that,
like
certainly,
we
threw
up
as
one
of
the
open
issues
right
like
you
know
to
see,
if
you
can
do
that,
but
your
point
is
well
not
in
mark
yeah.
Thank
you.
F
Yeah
but
anyway,
I
want
to
note
that
we
are
mainly
addressing
a
problem
here
that
we
mainly
have
on
the
ietf
stream
and
therefore
there's
the
main
focus
on
that
stream.
A
Okay
thanks
robert
you're
next.
J
So
I'm
going
to
plus
one
mark
fairly
hard.
I
understand
that
the
ihf
stream
gives
us
the
best
sample
pool
for
trying
to
understand
whether
or
not
we
have
a
better
set
of
descriptors
for
tags,
but
I
think
that
the
presentation,
the
use
of
these
tags
figuring
out
how
the
the
metadata
would
would
end
up
being
displayed
in
in
the
long
term
and
how
software
would
be
written
to
leverage
the
existence
that
metadata
is
going
to
need
more
than
the
ietf
looking
at
it
closely.
J
I
think
that
there's
still
unclarity
around
the
the
tags,
as
proposed
so
far,
and
that
there's
that
we
just
need
to
continue
the
discussion
on
that
and
a
final
point
that
I
would
like
to
throw
in
is
that
if
we
go
with
anything
that
has
the
semantics
of
the
currently
proposed
see,
also,
I
anticipate
that
you
will
very
quickly
also
and
have
to
include
a
rule
like
you
have
now
on
the
limit
of
the
number
of
authors
that
can
be
on
an
rsc
to
limit
the
number
of
sea
alsos,
because
I
suspect
that
would
end
up
being
kitchen
synced
very
quickly.
F
So
before
you
disappear,
I'm
actually
not
fully
understand
the
the
tooling
or
the
semantics
point
here,
because
what
we're
doing
is
replacing
one
tech
that
already
exists
with
three
different
texts
which
which
exist,
which
replace
the
usage
that
we
have.
So
it's
not
like
we're,
inventing
something
completely
new.
We
already
have
text
and
we
we
know
how
to
link
our
c's
rate
is
just
like
we're
using
a
different
word
here.
That's
it!
So
I
don't
really
understand
the
issues
here.
You're
describing.
J
Well,
I
think
that
we
are.
We
must
be
past
talking
past
each
other,
because
I
do
see
still
some
significant
issues
in
the
confusion
that
lies
around
updates
still
lying
arounds
in
in
the
the
current
definition
that
you
have
for
extends.
J
E
Okay,
so
robert,
can
you
send
some
comments
to
us
like
either
on
list
or
off
list?
Like
you
know
where
you
see
the
lack
of
clarity,
so
we
can
make
an
update
for
handling
that
while
leaving
the
tool
issue
aside
and
the
venue
issue
aside,
like
you
and
mark
said,
like
to
kind
of
figure
that
out
like
separately
from
that,
because
I
I
think
it's
important
for
us
to
kind
of
like
swat
down
any
bugs
about
a
lack
of
clarity,
because
this
is
an
intent
to
clarify.
E
J
I
I
could
try
to
send
text,
but
the
text
has
already
been
sent
several
times
and
I
don't
think
you're
hearing
it
so
to
put
a
very
fine
point
on
it.
Your
proposal
for
extends
is
already
taken
care
of
it's
use
of
code
points.
You
don't
need
it
rename
updates
to
be
amends
and
walk
away
from
the
whole
problem.
This
is
what
several
people
have
said.
E
F
So
I
I
want
to
say
one
more
thing
like
because
you
said
we're
not
listening,
so
there
have
been
many
proposals
to
only
replace
it
with
one
tech
to
remove
updates
completely.
We
are
proposing
three
tags
here
right
and
like
for
me:
there's
no
clear
consensus.
Yet
what
we
want
to
do,
but
the
reason.
C
F
We've
presented
today,
we've
been
presenting.
This
data
is
to
actually
show
that
we
didn't
make
up
these
texts
out
of
nothing
right.
This
is
how
the
updates
text
has
been
used
so
far,
so
we're
just
trying
to
get
a
little
bit
more
clarity
in
what
the
community
has
done
so
far
and
not
changing
what
the
community
has
done
so
far.
A
Okay,
thank
you
just
in
the
interest
of
time
and
we'll
just
hear
from
lars
and
rob,
and
then
I'll
summarize
just
to
say
that
a
couple
of
comments
in
jabba,
suggesting
that
this
discussion
shows
a.d
sponsorship
is
maybe
not
the
way
forward.
For
this
and
elliot
lears
said
that
maybe
a
mailing
list
could
be
formed
and
the
draft
continued
to
be
developed
there,
and
then
we
can
hope.
The
new
rfc
process
comes
to
conclusion.
Soonish
yeah
over
to
you
last.
K
Different
point,
so
so
I'm
actually
a
big
fan
of
this
draft.
I
think
it's
it's
really
helpful
for
implementers
and
to
understand
so
it's
key
information.
It's
really
hard
to
pick
out
today,
so
I
like
the
uses
metadata,
but
I
think
it's
helpful.
I
think
it's
also
helpful
for
the
isg,
because
again
we
have
the
same
issue
about
what
does
updates
mean
and
it
comes
around
multiple
times.
I
think
that
this
would
help
both
the
isg
sort
of
converge
on
what
the
definitions
are
and
also
the
working
groups
as
well.
K
The
authors
when
they're
writing
these
things,
I
think,
is
helpful
from
that
point
of
view
I
did
like
and
to
copy
sort,
barry's
comments.
I
liked
the
idea
of
having
guidance
as
to
making
sure
the
document
specifies
as
to
what
the
updates
are
and
what
the
amends
is.
I
think
that
makes
sense
and
would
be
helpful.
The
one
other
comment
I
want
to
add
that
hasn't
discussed
here
is
that
this
is
metadata
between
rfcs
and
one
question
I
have
is
at
the
moment
we
have
the
ability
to
update
that
metadata.
F
It's
only
half
of
this
is
only
metadata
right,
so
the
updates
text
itself
is
actually
part
of
the
rc.
Only
what
you
add
to
the
updated
rfc
is
metadata,
and
that
is
changeable.
K
F
F
I
think
that's
actually
a
question
for
the
rsc
editor
or
the
future
group
talking
about
this,
because
that
would
be
a
larger
change.
K
Yeah,
so
so
in
terms
of
dispatch,
I
I
feel
that
for
lots
of
these
things
that
to
me
feel
like
a
relatively
minor
enhancement,
we
spent
quite
a
lot
of
time
discussing
these
and
discussing
the
process
and
the
way
forward,
and
I
would
like
to
find
some
way
to
make
this
sort
of
more
expedited
and
quicker.
My
dispatch
recommendation,
I
think,
picking
up
what
elliot
said,
I
think,
having
an
email
maybe
set
up
to
discuss
this
and
refines
further
makes
sense,
and
I
would
probably
see
ads
sponsored
as
being
the
most
expedient
process.
F
Thanks,
thank
you.
I
would
quickly
like,
because
I
promised
ellie
to
do
that.
F
He
had
a
clarifying
question
in
the
chat,
so
he
asked
what's
the
difference
between
just
using
a
reference
and
see
also
so,
reference
is
just
a
reference
to
an
existing
rfc,
but
if
you
actually
want
to
add
something
to
the
existing
rfc
to
point
to
a
future
or
to
new
rsc,
that's
where
you
need
to
see
also
and
by
maybe
addressing
another
concern
that
came
up
is
because,
because
of
that,
you
have
to
think
you
know
what
what
does
the
old
rc
need
is
it?
F
Is
it
important
for
the
reader
of
the
old
rsc
to
see
this
new
receipt?
Just
it
doesn't
mean,
like
c
also
doesn't
mean
these
two
documents
belong
together,
but
it
means
the
old
reader
of
an
old
rsc
should
also
look
at
this
new
rfc
and
because
it's
not
only
a
reference.
I
think
it
would
be
much
more
badly
used
than
references,
so
I
would
hope
that
c
also
really
doesn't
show
up
that.
C
Yeah
hi
last
I
got
speaking
as
an
individual,
so
I
actually
have
a
slightly
different
question.
I'm
sort
of
looking
at
the
first
poll
that
it
says
run
as
an
experiment
or
propose
a
bcp.
I'm
I'm
wondering
if
you
could
say
a
bit
more
about
what
the
experiment
would
look
like,
because
I'm
slightly
worried
that,
if
we're
temporarily
adding
new
metadata
or
export
new
data,
if
you're
thinking
about
stuff
going
into
the
rendering
of
the
document
right
and
then
we
decide
the
experiment
failed
it.
C
We
would
have
an
rfc
stream
or
multiple
streams
where
we
have
like
you
know,
we
had
metadata
for
some
documents
and
and
or
we
are
rendering
for
some
documents.
So
it's
the
proposal.
We
would
like,
then
remove
that
from
from
the
database
or
we
would
like
keep
it
in
there
and
people
would
be
confused
10
years
later.
What
this
is
and
these
few
documents
show
it,
or
can
you
say,
but.
E
F
If
it's
an
experiment,
then
one
thing
is
currently
because
it's
bcp,
we
actually
say
the
old
update
stack,
is
obsolete.
So
for
an
experiment,
I
think
we
should
keep
the
old
tech,
so
at
least
we
always
have
the
old
way
to
have
it
right
and
then
we
just
add
the
new
text.
In
addition,
and
then
at
some
point
we
can
decide
what
what
to
do,
keeping
the
old
one
or
using
the
new
ones
and
removing
something
on
on
published
rcs
is
a
little
bit
harder.
F
E
A
E
Have
yeah
like
I
had
another
idea
as
well
media
right,
like
so
large,
like
I
think,
if
you're
going
to
do
this
as
an
experiment,
I
would
do
both
of
the
tags
as
metadata
like
none
of
them
appearing
on
the
rfc,
at
least
as
an
experiment
like
you
can
do
the
right
now.
One
of
them
is
part
of
the
rfc
another
one.
Is
that
metadata
metadata
tag
so
like?
If
you
do
this
as
an
experiment,
we'll
just
like
keep
it
as
metadata
attacks
on
both
sides?
A
Okay
thanks
everyone
and
for
your
comments
and
answering
the
dispatch
question
chairs
have
been
discussing
and
we
hearing
support
to
take
this
to
a
mailing
list
and
then
to
we
think,
that's
a
quite
clear
desire
and
then
whether
the
new
rfc
process
takes
on
after
that
is
a
possibility,
but
to
continue
working
on
this
draft
and
yet
create
a
mailing
list.
Just
for
this.
A
Okay,
so
thanks
everyone
thanks
to
our
presenters
as
well,
for
taking
us
through
that
not
seeing
any
kind
of
anyone
rushing
to
the
queue
to
disagree
so
we'll
leave
it
there.
Thank
you
and
lars
you're
presenting
next.
Would
you
like
to
do
the
slides
or
should
I.
A
C
C
Think,
thank
you.
So
this
is
a
not
as
iotf
chair,
but
as
an
individual,
but
I'll
get
to
that.
So
this
is
a
proposed
revision
of
bcp
45
aka
rfc
3005,
which
is
the
itf
discussion.
Discussion.
Discussion
list
charter
next
slide,
please
see
so
for
background
right.
C
In
april
2020
again
the
previous
isg
concluded
that
the
last
call
experiment
was
successful
and
there
were
two
actions
promised.
One
of
them
was
a
revised
isg
statement
on
stuff
and
then
the
update
to
bcp
45.
that
was
not
initiated
at
the
time
in
april
2020..
C
It
was
pointed
out
that
that
was
something
that
would
need
to
be
done
still
so
so
this
document
was
an
attempt
to
deliver
this
sort
of
promised
update
and
and,
as
I
started,
putting
this
together,
the
intent
was
very
much
for
this
to
be
the
most
minimal
update
to
bcp
45
that
we
could
do
to
reflect.
The
creation
of
the
last
call
mailing
list,
and
the
I
think
already
before
I
posted
is
there
were
proposals
to
more
significantly
revise
the
itf
discussion
list.
C
Bcp
45
was
written
next
slide,
so
the
major
changes
from
bcp-45
are
reasonably
there's
reasonably
few
of
those
right,
so
we're
referencing,
basically,
two
new
lists,
one
of
them
being
last
call
the
other
one
being
admin
discuss
where
discussions
are
now
supposed
to
take
place
that
at
the
writing
of
pcp
45
were
taking
place
on
the
main
idf
discussion
list
and
there
was
some
some
other
cleanups
that
happened
alongside
this.
But
but
I
would
say,
that's
that's
the
major
change.
C
The
second
major
change
was
a
suggestion
from
the
sergeant-at-arms
teams
to
expand
on
the
description
of
their
operation
and
purpose
and
so
on,
and
that's
because
bcp
45
is
extremely
short
on
on
what
the
sergeant-at-arms
are
and
how
they're
operating
and
and
the
team
felt
that
it
would
be
helpful
if,
if
a
bit
more
was
documented
about
how
they're
operating
at
the
moment,
I
think
there
was
a
comment
from
keith
moore
on
the
list
that
we
like
didn't
want
to
see
this
description
of
how
the
team
currently
operates
in
the
draft.
C
I
noted
that
I
think
there's
three
options
for
this
particular
bullet.
C
One
is
roll
it
back
to
what
bcp
45
said
or
rc
3000
five
set,
which
isn't
a
whole
lot
other
than
they
exist,
and,
and
they
can
moderate
people
option
two
is
what
I
picked
is
to
describe
what
the
saa
team
has
been
giving
themselves
as
operating
procedures
for
a
number
of
years
now,
and
basically
just
describing
the
current
state
of
the
art
and
option
three
would
be
to
describe
some
some
other
way
in
which
the
sergeant-at-arms
team
should
be
selected
and
operated.
G
C
Me
that
feels
like
something
that
we
might
want
to
discuss
as
part
of
a
more
significant
revamp
of
the
ihf
discussion
list,
but
if
the
community,
you
know,
wants
to
put
it
into
this
revision,
I
guess
we
could
next
slide
right.
So
the
next
step
is
that
o3
was
submitted
on
on
monday.
Sorry
for
missing
the
cutoff.
It
rolls
in
all
the
pending
changes
that
I
sort
of
had
hanging
I'd
like
to
see
this
dispatched.
C
I
think
ad
sponsor
would
sort
of
look
like
the
natural
route
if
we
wanted
to
publish
this
and
also
been
pointed
out
on
the
list
that
maybe
the
optics
of
the
ietf
chair
authoring,
this
document
are
all
that
great.
I
didn't
really
think
about
that.
When
I
started
it
seemed
like
a
small
thing
that
the
previous
isg
had
offered
to
the
promise
to
the
community,
and
I
figured
I'll
just
you
know,
write
this
myself
real,
quick
and
we're
done
with
it.
C
Maybe
it
wasn't
so
quick,
and
maybe
we're
not
so
done
so
if
somebody
feels
that
somebody
else
should
hold
the
pen
on
this,
I'm
very
happy
for
this
to
happen
right.
So
my
name
does
not
need
to
be
on
this
document
for
clarification
and
I
think
that's
the
last
slide.
Thank
you.
B
All
right,
thanks
lars,
so
we
have
elliot
in
the
queue
first
go
right
ahead.
L
Hi
good
afternoon,
good
evening,
good
morning
to
everyone
lars
thanks
for
doing
the
draft
and
sorry
I've
been
a
little
bit
of
a
pain
in
the
ass
on
the
gen
dispatch
list.
About
this.
You
know
the
draft
is
innocuous
in
itself.
I'm
sure
other
people
might
have
some
issues
here
and
there,
but
this
isn't
my
primary
issue.
L
My
primary
issue
is
that
we
seem
to
be
sort
of
nipping
at
the
edges
of
how
we
communicate
as
a
community,
and
I
wonder
if
we
could
find
a
way
to
take
that
sort
of
conversation
forward
in
terms
of
looking
at
different
ways
to
improve
the
discourse
as
a
a
community
as
we
go
forward
not
for
purposes
of
draft
development,
but
to
handle
the
sorts
of
problems,
for
instance,
that
joel
raised
in
in
the
context
of
well.
L
You
know
how
do
we
even
have
a
whole
discussion
about
modalities,
for
instance-
and
you
might
say:
well
that's
the
ietf
but
the
ietf
list,
but
I
don't
think
that
it
works
the
way
anybody
really
wants
it
to
at
this
point,
and
so
that's
the
or
at
least,
certainly
it
doesn't
for
me.
L
I
don't
think
it
does
for
for
the
people
who
have
left
the
list,
and
I
I
would
just
like
to
see
some
sort
of
evolutionary
process
to
try
and
get
us
to
a
better
place
in
terms
of
how
we
communicate
with
one
another.
Thanks
very
much.
L
Sorry,
sorry
pete
the
dispatch
question,
given
the
the
the
level,
the
draft
I'd
love
to
hang
over
the
the
answer
of
this
question.
Yes,
lars
will
commit
to
try
and
work
on
this
evolutionary
thing,
but
I
won't
do
that.
It's
it's
a
simple
enough
thing
that
I
would
say
just
go
with
an
a.d
sponsored,
but
I
really
would
ask
that
you
answer
to
me.
If
you
can,
you
know
some
way
to
take
this
other
conversation.
B
C
So
I
want
to
quickly
respond
to
elliot,
if
I
can,
oh
yeah
sure,
go
ahead
norris,
so
I
agree
so,
and
so
so
there
is
a
broader
discussion
that
needs
to
be
had
about.
You
know
how
we
communicate
as
a
community
communicate
as
a
community
right,
and
I
think
that's
what
some
of
the
other
proposals
that
maybe
mark
wants
to
talk
about
the
ones
that
he
made
rob
sayer
made
one.
I
think
that's
that's
also
something
that
the
isg
is
sort
of
interested
to
figure
out.
C
That
is
not
this
document
right.
This.
This
document
is
basically
trying
to
close
a
loop
on
something
that
you
know
brings
an
an
old
piece
of
text
in
line
with
reality,
which
you
know
points
out
to
me
that
these
other
mailings
exist
where
we're
gonna.
This
discussion
has
moved
and-
and
we
don't
want
to
have
the
confusion
that
somebody
looks
at
rfc
3005
and
you
know,
doesn't
understand
that
last
call
and
that
we
discuss
are
places
where
things
are.
I
I
This
is
just
doing
the
tours
around
the
house
sort
of
stuff.
It's
it's
not!
You
know
anything
controversial.
I
think
there's
been
some
objection
to
it
that
it
isn't
what
some
people
want
it
to
be
in
terms
of
being
a
bigger
thing.
That's
not
a
well-formed
objection
against
a
document
like
this
going
forward.
It's
just
reflecting
the
reality
of
how
we
work
now.
So
yes,
please
go
forward,
80
sponsored
regarding
the
bigger
conversation
and
how
we
work
together.
I
Frankly,
I'm
somewhat
pessimistic
about
making
progress
on
that
on
that
front,
I
don't
think
that
getting
a
bunch
of
people
together.
I
List
or
in
a
in
a
room
and
hashing
it
out,
is
going
to
give
us
significant
progress.
So
if
we
are
going
to
make
progress
there,
I'm
looking
to
the
isg
for
leadership
there.
We
need
to
find
some
creative
way
out
of
the
box
we're
in,
but
but
more
arguing
is
probably
not
going
to
help.
That's
why
I'm
not
subscribed
to
the
itf
list
and
regarding
the
authorship
of
the
draft,
largely
you
remember
this
community.
I
Yes,
so
I
I
would
strongly
argue
that
you
have
every
right
to
author
a
draft
in
the
itf
and
if
someone
is
talking
about
optics,
I
think
that
implies
that
they
don't
think
that
the
process
actually
is
fair
and
has
the
right
checks
and
balances,
and
I
would
object
to
that
as
well.
So
please,
author,
this
draft.
Unless
it's
a
workload
issue
for
you,.
C
Thanks
noted,
I
have
one
other
comment
for
you,
so
I
am
actually
personally
pretty
nervous
if
we're
asking
the
isg
to
determine
how
the
community
should
communicate
going
forward.
C
So
I
understand
that
not
necessarily
we're
in
a
deadlocked
situation
with
multiple
proposals
and
very
different
viewpoints,
but
but
I
I
do
see
the
danger
that
if
the
isg
makes
a
proposal
here
that
it's
being
taken,
as
you
know,
leadership
dictating
quote-unquote
to
the
community
how
they
should
communicate,
and
I
would
be
much
happier
if,
if
proposals
will
come
from
the
community
and
they
manage
to
get
traction,
but
that's
not
the
discussion
we
should
have
for
this
document.
C
B
Offline
and
speaking
personally
glad
to
participate
in
that
offline
discussion,
but
phil
you're
up.
B
Nope,
so
what
I'll
leave
you
in
the
queue
and
you
can
play
with
your
microphone
and
john?
Why
don't
you
go
ahead
while
phil
is
trying
to
figure
out
his
input.
G
I
I
I
like
this
draft,
I
think
straightening
out
this
mess
is
a
fine
idea
and
and
given
where
we
are,
I
think
he'd
be.
Sponsoring
is
probably
the
right
answer,
but
for
the
record
and
congenital
strategy,
I
am
deeply
concerned
about
the
optics
of
a
proposal
originating
a
proposal
or
a
problem
statement
originating
from
the
isg,
an
ist
author
and,
ultimately,
an
isd
approval.
It
just
smells
bad
and
long
term.
B
M
Okay,
I
got
a
bunch
of
suggestions
on
the
this
particular
draft.
I
mean
basically,
the
fault
that
happened
was
that
when
the
experiment
was
run,
the
draft
should
have
been
updated
then,
and
so,
if
we
think
of
it
in
that
those
terms
doing
it,
a.d
sponsored
just
to
clear
it
away.
That's
fine!
M
As
far
as
the
wider
question,
I
think
that
probably
what
we
need
to
be
looking
at
is
shmu
needs
to
become
a
general.
M
How
do
we
re-engineer
the
itf
in
that
it
looks
very,
very
possible
that
we
might
be
meeting
virtually
for
more
than
a
year
or
two
years
from
today
the
there
are
bigger
engineering
problems
that
we're
going
to
be
facing
than
just
the
itf
list,
but
the
other
thing
that's
rather
strange
I
find
is
we
have
this
particular
three
times
a
year
meeting
with
the
idea
that
we're
meant
to
be
collaborating
across
working
groups
and
areas
or
whatever,
and
we
can't
even
run
a
single
damn
mailing
list
and
have
everybody
talking
on
it.
M
So
I
think
that
we
need
to
think
very
carefully
about
what
our
common
meeting
points
are
and
there's
much
more
here
than
just
one
mailing
list
involved.
B
Thanks
phil,
I
I
I
think
this
so
far.
What
I've
heard
and
kirsty
can
speak
up
as
well.
B
Is
that
folks
seem
generally
in
favor
of
this
being
ad-sponsored
and
get
it
done,
because
it
is
a
set
of
changes
that
people
think
are
reasonable
and
should
go
forward
that
there
are
bigger
picture
questions,
but
I
haven't
quite
heard
a
well-formed
enough
dispatch
thing,
let
alone
a
document
to
dispatch
on
that
question,
and
so
maybe
we
can
talk
offline
about
setting
up
a
forum
for
where
that
even
discussion
of
that
discussion
should
start
lucy.
You
wanted
to
jump
in.
N
I
have
a
couple
of
questions
about
both
the
use
of
the
discuss
list,
as
it's
described
in
large
your
document,
as
opposed
to
on
the
discussion
lists
page
where
policy
is
included,
and
there
are
some
additional
constraints
around
talking
about
meetings
and
in
following
the
list
just
in
the
last
week,
both
attendees
and
the
regular
list.
I
know
there's
a
feedback
problem
between
schmoo
many
couches
admin
and
the
general
discuss
list,
and
there
might
be
some
guidance
here
about
when
it's
appropriate
for
those
lists
to
report
back
to
discuss.
C
So
fair
point,
I
I'm
my
impression
is
that
the
the
mailman
text
about
the
discussed
list
has
probably
not
been
updated
very
actively.
C
Got
it
if
you
could
stick
me
the
url
in
the
in
the
chat,
I
will
open
an
issue.
Thank
me.
I
did
it
already.
Thank.
N
C
Great
greg
waters
in
in
in
the
process
of
updating
various
pages
on
on
the
ietf.org
mail
as
the
conference
director,
and
I
think
he
might
sort
of
have
moved
in
the
direction
of
making
updates
that
should
be
brought
into
line
with
this
document.
If
it
gets
published
or
when
it
goes
forward
to
being
published
and.
C
Yeah
fair
point
along
the
issue
of
coordination
between
the
different
lists
that
we
have
now
right.
I
I
hear
you,
but
I
think
this
is
also
part
of
the
broader
discussion
about
you
know
whether
we
can
have
an
organizational
organization-wide
channel
of
some
sort
and
what
that
would
look
like
and
and
how.
Why
would
people
want
to
be
on
it
if
they
didn't
want
to
be
on
the
itf
discussion
list?
So
that's
something!
I
think
this
is
an
important
topic.
It
keeps
being
brought
up
by
various
people.
C
C
I
think
I
don't
want
to
speak
for
the
chairs,
but
I
think
the
discussion
about
this
could
probably
be
on
gen
dispatch,
as
it
is
more
here
than
in
shmu,
which
is
very
much
focused
on
remote,
only
meetings
at
the
moment,
if
shmu
ever
recharges,
we
it
might
the
the
parts
of
it
that
affect
meetings
might
touch
on
shmu,
but
I
think
schmooze
very
much
meaning
focused
so
so
genders,
which
I
think
is
the
list
we
have
for
this
at
the
moment
or
we
make
a
new
one
right.
That's
the
other
option.
B
If
I
I
mean
we
have
in
the
past,
if
the
discussion
hasn't
doesn't
continue
to
get
bogged
down,
been
happy
to
allow
the
gen
dispatch
to
get
get
some
document
done
that
we
have
dispatched
as
ad
sponsored,
but
if
it
does
start
getting
very
noisy
in
the
traffic,
we
might
come
back
to
you
and
ask
a
different
question.
B
So
I'm
I'm
hearing
relatively
you
know,
I
mean
maybe
not
wildly
strong
support
but
good
support
for
ad
sponsoring
this
and
lars
or
somebody
else
perhaps
rob
I
heard
rob's
name
mentioned.
There
is
an
ad
who.
B
K
Yes,
I'm
I'm
willing
to
80
spots
this
and
I'm.
It
seems
like
the
community's
happy
for
last
to
be
the
author
on
this
and
it's
given
he's
written
it.
I'm
also
happy
that
he
continues
to
be
the
author.
B
Yeah
I
mean
I
take
john's
point
about
optics
and
internal
iasg
things
and
it
can
look
like
the
aiesg
taking
some
point
of
you
know
power,
but
on
the
other
hand,
perhaps
that's
something
to
be
explained
to
the
community,
and
you
know
at
least
so
far
in
this
room.
We've
heard
pretty
good
support
for
it's.
Okay,
for
this
particular
case,
for
these
reasons
that
this
be
80
sponsored
even
written
by
the
ietf
chair.
B
B
A
Thanks
pete
yeah,
so
this
is
a
metagen
dispatch
item.
Where
we're
going
to
talk
about
gender
dispatch
itself,
so
hi
everyone.
This
is
my
first
time
chairing
a
co-chairing
gen
dispatch,
kirsty
payne,
I'm
new
to
this
group.
It's
actually
my
10th
itf.
A
So
I
feel
like
I
deserve
a
cake
made
that
joke
in
my
other
chairing
group
as
well,
but
it
never
gets
old.
So
we're
going
to
talk
about
gender
dispatch
updates,
because
gender
dispatch
was
charted
in
september
october
2019,
it
depends
which
date
you
choose,
and
I've
just
copied
a
bit
from
the
charter
here
in
the
second
bullet
point
that
it's
a
dispatch
style
working
group
which
is
charted
to
consider
proposals
for
new
work
in
the
gen
area.
A
So
it's
not
doing
any
technical
standardization
work
itself
is
just
identifying
or
helping
to
create
appropriate,
appropriate
places
for
the
work.
And
importantly,
the
charter
says:
a
review
of
the
efficacy
of
this
working
group
will
be
undertaken
18
to
24
months
after
its
chartering
and
for
those
of
you
still
awake
wherever
your
time
zone.
That's
now.
A
So,
let's
review
gender
spatches
efficacy
and
we'd
like
views
from
the
community
and
we're
just
starting
it
in
this
meeting,
but
we'll
continue
discussions
on
list
as
well
for
those
who
aren't
here
or
if
you
have
other
thoughts
after
today.
So
just
a
reminder.
The
gen
dispatch
process
gives
us
these
ground
rules
and
possible
outcomes,
so
the
ground
rules.
We
just
recommend
next
steps
for
new
work.
A
We
did
not
adopt
drafts,
only
dispatch
does
adopt
drafts,
actually
select
dispatch
doesn't
adopt
either
and
our
possible
outcomes
at
the
moment
are
directing
to
an
existing
working
group
propose
a
new
focused
working
group
to
recommend
ad
sponsorship
assuming
a
willing
id
it
can
go
back
into
the
community
for
more
discussion
or
development
or
another
recommendation
might
be
that
we
shouldn't
itf
shouldn't
work
on
this
topic,
so
to
help
kind
of
spark.
Some
thoughts
about
gender
dispatch
here
are
some
stats
love
a
good
table
so
we've
met.
A
A
I
love
a
good
bar
chart
as
well,
so
this
is
a
blue
sheet
attendees
per
meeting
for
106
107,
108,
109
110.
and
obviously
today
we
have
46
people
on
the
call
at
the
moment,
roughly
from
from
me
taco.
So
we
also
have
the
gender
dispatch
email
list.
That's
created,
27th
of
september
2019
has
79
members
when
I
checked
yesterday
and
it
had
940
emails.
When
I
checked
yesterday
as
well.
So
that's
the
end
of
my
stats.
There
are
probably
more
stats
I
could
have
gathered,
but
I
didn't.
A
If
you
have
ideas
for
other
stats,
you
would
like
to
see
and
that
might
help
you
review
the
efficacy
of
gender
dispatch.
Then
you
may
find
them
yourself,
but
the
whole
point
is
just
to
start
your
thinking
and
get
your
feedback
really
on.
Is
there
still
a
need
for
something
like
gen
dispatch?
It's
kind
of
an
experiment,
that's
been
around
for
a
couple
of
years.
Nearly
is
it
working.
A
Would
you
like
to
see
it
continue
and
that
could
be
with
or
without
changes,
but
just
in
some
form,
would
you
like
to
see
it
continue?
Is
gender
dispatch
a
useful
group
in
its
current
state?
Do
you
think
gender
dispatch
would
be
more
useful
with
some
changes
and
if
you
do,
what
would
those
changes
be
and
then
just
any
other
feedback?
A
A
So
that's
really
all
from
me
do
join
the
queue
I'll
manage
the
the
queue
myself
and
if
you
have
any
comments
in
java
as
well
I'll
check
that
and
read
those
out
as
as
needed
so
joel.
Take
it
away.
O
Thank
you
as
someone
who
has
written
a
document
that
made
it
through
gen
dispatch
and
is
working
on
a
document
which
I
cannot
imagine
how
gen
dispatch
will
dispatch
it.
I
think
that
that,
for
some
things,
gen
dispatch
is
working.
O
O
I
know
what
a
good
way
is,
but
gen
dispatch
can't
cope
with
them,
and
so
I
think
we
need
to
figure
out
what
is
it
going
to
take
to
get
the
ietf
able
to
deal
with
bigger
procedural
questions
and
once
we
know
that
we
can
then
determine
whether
keeping
gen
dispatch
to
deal
with
small
things
is
the
right
answer
or
whether
that
that
other
solution
can
take
care
of
it.
I
don't
know,
but
gen
dispatch,
as
defined
simply
can't
cope
with
some
of
what
I
consider
very
important
issues.
Thank
you.
A
Okay
yeah.
So
thanks
for
your
comment,
I'm
I'm
just
making
notes.
Sorry
if
I
look
distracted
so
yeah
you're,
just
saying
it's
not
very,
maybe
as
currently
set
up
good
to
deal
with
kind
of
bigger
procedural
questions,
and
it
deals
with
small
things
pretty
well
and
maybe
there's
need
for
another
solution
or
for
gender
spatch
to
change
in
some
way
to
be
able
to
deal
with
bigger
things
if
needed.
K
Yes,
sir,
so
my
question,
I
think,
is
over
the
choices
that
gender
dispatch
has
today
and,
in
particular,
for
small
bits
of
work.
Dispatching
to
be
ad
sponsored
seems
to
make
sense,
but
things
are
a
bit
larger
that
you
may
still
want
more
community
review.
It
feels
like,
in
some
of
those
cases,
spinning
up
a
separate
working
group
for
a
specific
document
is
potentially
too
much
work
and
ad
sponsored
is
maybe
a
little
bit
too
little.
K
I
do
wonder
whether
having
a
working
group
to
sort
of
process
process-based
documents
would
be
handy
that
could
either
be
doing
work
directly
in
general.
Dispatch
might
be
one
choice
or
another
one
would
be
have
a
separate
working
group.
That's
aimed
to
sort
of
take,
take
off
and
process
those
documents
like
the
one
that
I've
just
accepted
to
be
ad
sponsored.
I
don't
think
there's
any
great
reason
that
document
needs
to
be
id
sponsored
if
there's
a
small
working
group
that
could
process
that
that
would
be,
I
think,
for
me
slightly
preferable.
K
I
see
a.d
sponsored
as
a
sort
of
root
of
last
resort.
So
that's
that's.
My
one
thought
here
is
that,
having
some
way
of
or
somewhere
to
process
process
related
discussions,
I
think
would
be
helpful.
I
don't
feel
necessarily
gender
dispatch
to
the
right
place,
but
but
it
could
be.
A
Thanks
thanks
robert,
for
your
view,
philip
you're
next.
M
Yeah,
just
following
on
from
what
robert
said,
what
really
is
the
difference
between
a
mailing
list
and
a
working
group
and
well
really?
The
difference
is
that
working
groups
hold
can
get
to
schedule
sessions
at
itf
meetings,
and
maybe
what
you
want
to
you
know,
because
there's
been
this
fast
issue
in
the
itf
that
we
don't
whole
have
standing
working
groups,
even
though
I
think
that
that
is
probably
what
you
want
to
do
for
you
know
for
protocol
is
active,
but
you
know
that's
possible.
M
M
I
think
they
still
need
something
like
gen
dispatch,
simply
because
she
needs
something
to
filter
the
ideas
before
you
then
go
on
and
do
something
because
you
know
you're
saying
that
gender.
You
know
the
dispatch
process
is
presented,
as
we
have
a
proposal.
Where
does
it
go
that
isn't
quite
what
happens?
The
proposals
do
actually
get
modified
in
the
dispatch
discussions
and
come
out
a
slightly
different,
and
so
I
think
that
there
is
a
a
value
in
gen
dispatch.
M
I
would
like
to
see
the
dispatch
template
be
something
that's
applied
to
every
itf
area.
You
know
just
as
a
matter
of
course,
and
that
you
know
we
apply,
we
adopted
insect
deer.
It's
been
very
valuable,
insect
deer,
because
before
that
there
was
no
place
that
you
could
see
that
you
could
take
your
idea
to.
M
I
think
that
having
that
visible
on
ramp
is
something
that
we
need
for
itf
process
and
gen
dispatch
is
the
on
ramp
for
the
itf
as
a
whole.
So
I
think
it's
needed.
A
Thank
you,
phil
yeah,
and
you
can
just
see
some
people
in
jabba
talking
as
well,
about
working
groups
also
having
a
charter
as
well
as
a
chair
and
mailing
lists
not
being
able
to
publish
documents
so
between
a
working
group
and
a
day
and
mailing
list
they've
got
their
different
advantages:
disadvantages.
A
There's
a
lot
of
chat
in
jabbard,
encourage
people
to
come
to
the
list,
even
if
they
have
a
kind
of
passing
opinion
on
this,
even
if
you're,
fairly
neutral.
That's
also
good
feedback.
So
I'll
just
pause.
L
E
L
We
handle
the
bigger
topics
that
occasionally,
probably
I
don't
think
they're
all
procedural.
By
the
way,
occasionally,
a
typical
one
will
crop
up
that
we
really
want
to
have
a
discussion,
and
so
you
know
it's.
I
think
it's
a
very
hard
question
to
answer.
In
this
context,
I
think,
to
a
few
of
us
at
least:
we've
gone
down
the
wrong
path
in
terms
of
fragmenting
all
the
discussions,
but
other
people
do
exactly
the
opposite,
which
is,
as
I
think,
mark
put
it
that
that's
essentially
a
holding
holding
the
entire
people.
L
A
So
I'll
just
pause
in
case,
anyone
else
would
like
to
oh
okay,
elliot
you're
still
in
the
queue
I'm
gonna
assume
that's
from
last
time.
Okay,
thank
you.
So
john.
G
Say
something
brief
and
extremely
radical,
I'm
wondering
as
a
former
chair
of
one
of
the
descendants
of
poised
the
fishing
one
I
am
wondering
if,
if
what
part
of
this
conversation
is
leading
to
is,
is
the
possibility
of
a
need
for
a
another
working
group
to
do
a
a
comprehensive
review
of
our
processes?
G
A
Direction
john
robert.
K
So
so
this
is
actually
to
in
response
to
to
john's
question.
I
would
be
I'd
actually
be
quite
clean
for
it
to
do
that.
So
within
the
isg,
I'm
relatively
new
to
itf
and
within
the
sg.
I've
looked
at
some
of
the
stuff
that
we
do
in
terms
of
process
and
how
those
those
are
documented
in
rfcs
and
many
rfcs
that
update
them,
and
I
feel
that
it's
very
hard
for
people
who
are
not
embedded
with
lots
of
knowledge
about
it.
K
You
have
to
understand
what
the
process
is
and
look
at
that
and
understand
it,
and
and
and
make
easy
progress
here.
So
we've
had
conversations
in
the
isg
as
how
we
could
improve
this,
but
there's
many
things
that
make
that
hard,
partly
because
it's
a
lot
of
work
to
do
that
in
terms
of
the
existing
process
and
partly
because
the
optics
of
the
isg
driving
that
I
think
is
potentially
not
right
or
or
potentially
wouldn't
be
received.
Well,
so
without
knowledge
of
how
it
ended
last
time
and
the
problems
that
were
involved.
K
I
I'm
quite
keen
that
if
there
was
some
effort
to
try
and
streamline
some
of
the
itf
it's
processes,
I
think
that
would
be
a
really
good
thing,
but
whether
that's
achievable
or
not-
I
don't
know,
and
that's
sort
of
quite
off
topic
for
what
kirsten
was
asking
in
gardening
gender
dispatch.
I
think
it's
within
the
general
area.
G
Well,
it
it's
certainly
within
the
general
area
and
and
if
you'd
like
to
have
a
discussion
sometime
about
why
I
I
find
the
idea,
terrifying
and
and
share
mirrors
converience
concerns
about
making
a
problem
so
broad
we
can't
possibly
solve
it.
As
I
said
happy
to
have
that
conversation,
I
think
it's
the
right
thing
to
do.
I
just
think
we
need
to
go
into
it
with
our
eyes
open.
G
A
Okay,
thank
you
dominique
you're.
Next,
in
the
queue.
P
Thank
you
and
I've
only
attended
a
couple
of
these
in
the
last
couple
meetings,
but
just
a
thought.
P
I've
heard
a
lot
about
process,
obviously,
and
that's
something
that
I
think
we're
all
concerned
and
interested
in
across
all
of
the
ietf,
but
but
I'm
wondering
if
jen
dispatch
should
try
to
maybe
take
on
a
couple
of
more
different
items
to
see
if
there
could
be
different
outcomes
or
variety
of
potential
options
for
dispatching
as
well
just
to
see
if
there's
other
uses
for
this
particular
this
for
gen
dispatch,
in
particular,
just
a
thought
just
throwing
that
out
there,
because
it
seems
like
it's.
P
It's
a
good
place
to
collect
a
number
of
different
potential
issues,
and
maybe
we
should
try
and
use
it
more.
The
next
time
around
thanks.
A
Thanks
dominique
so
I
think
maybe
it
might
have
been
the
last
agendas
match
that
one
of
the
options
was
kind
of
updating
the
web
page.
We
weren't
really
able
to
dispatch
it
that
way.
It's
not
an
option
for
gender
dispatch,
so
cool,
I'm
not
seeing
anyone
else
in
the
queue
and
jabber
is
chatty,
but.
A
I
don't
think
there's
anything
to
relate
it's
just
kind
of
ongoing
discussion
about
like
making
sure
that
these
kind
of
process
questions
are
dispatched
properly
and
that
there's
an
opportunity
for
the
group
to
discuss
it
and
everything
so
that
I
think
indicates
that
genders.
Batch
still
has
a
useful
function,
and
that
is
a
good
place
for
the
community
to
discuss
these
kind
of
process
issues
and
new
proposals
and
new
work.
So
thank
you.
A
I
mean
we'll
continue
this
discussion
on
the
list
as
well
and
ask
these
questions
on
the
list
and
kind
of
get
a
few
a
few
more
inputs,
but
at
the
very
least,
I
feel
pleased
that
we've
done
the
review
after
18
to
24
months
of
gender
batch
chartering.
Pete.
Do
you
have
anything
you'd
like
to
add?
I.
B
I
guess
one
question
would
be:
does
does
lars
have
anything
in
particular
on
this
18
to
24
month
review
that
you
think
we
haven't
done
yet.
C
The
short
answer
is
no.
The
long
answer
is,
I
only
started
really
following
jen
dispatch
when
I
became
chair,
and
so
it
wasn't
even
on
my
horizon,
we're
at
the
point
where
this
review
needed
to
happen
right.
So
I
think
it's
working
right.
I
mean
there's
some
at
least
what
I've
sort
of
seen.
You
know
we
can
argue
that
big
things
are
are
difficult
to
dispatch,
and
that
is
true,
that's
also
true
in
the
technical
dispatch
groups
that
we
have
in
the
iitf
right.
So
this
is
not.
C
Only
process
related
but
but
I
think,
there's
a
value
in
having
this
group
around
to
give
some
early
feedback
and
some
early
direction
to
a
new
process.
Ideas
right-
and
I
think
if,
if
we
didn't
have
have
this,
we
need
something
else
like
it,
and
so
I'm
actually
in
favor
of
of
like
going
down
the
road
we've
been
going
down
with
some
tweaks.
Potentially,
this
is
hence
hence
the
feedback
here,
but
I
don't,
I
see
no
reason
like
to
close
gen
dispatch
or
to
significantly
change
the
scope.
B
Okay,
have
we
gotten
to
the
part
of
our
agenda
for
any
other
business?
Now
I
believe
any
other
business
things
that
people
see
coming
that
you
want
us
to
be
aware
of.
G
C
Discussion
that
was
started
on
the
attendees
list,
and
also
it
happened
on
the
schmue
many
cultures
list,
many
times
about
hybrid
meetings.
Right,
if
you
recall,
schmooze,
is
chartered
to
talk
about
remote,
only
meetings
and
and
provide
guidelines
for
those
if
people
would
want
to
start
discussing
hybrid
meetings
and
what
that
might
mean.
C
I,
the
question
is:
where
should
that
happen,
and
my
I
talked
to
this
movie
shares
and
the
the
best
home
for
this
is
probably
the
many
cultures
list.
Although
the
working
group
isn't
chartered
to
work
on
this,
it's
certainly
sort
of
where
the
people
who
might
have
opinions
and
ideas
about
this
problem,
space
hangout,
so
gender
dispatch
isn't
it.
I
think
this
discussion,
that
should
should
happen
on
schmoo
and
it
will
likely
move
over
when
the
attendees
list
will
close
at
the
end
of
the
meeting.
B
I
think
we've
got
relatively
good
direction
on
both
of
the
documents
and
and
what
we
need
to
do
so
on
the
bcp
45
update,
it
sounds
like
80
sponsored
is
going
to
be.
Okay
and
discussion
will
at
least
start
on
the
gen
dispatch
list.
If
there
are
things
that
seem
to
need,
adjusting
and
we'll
kick
it
off,
if
things
get
out
of
control-
and
you
summarize
the
first
document
kirsten.
A
B
Q
A
The
first
document
was
to
create
a
mating
list
and
then,
when
the
new
rfc
process
is
more
finalized,
that's
a
possibility
for
the
work
to
go.
There
eventually.
B
So
I
think
we've
got
solid
basis
for
the
minutes
and
thank
you
again
for
those
who
took
on
john
and
dominique
getting
those
minutes
in
order
and
we'll
do
our
edits
as
needed.