►
From YouTube: IETF111-RFCEFDP-20210729-2030
Description
RFCEFDP meeting session at IETF111
2021/07/29 2030
https://datatracker.ietf.org/meeting/111/proceedings/
B
B
All
right,
we
can
at
least
do
the
the
simple
stuff
nodewell
it's
thursday,
hopefully
for
this
crowd-
everybody's
seen
it
before.
Please,
please
do
note.
Well,
this
is
our
agenda
very
simple,
we'll
be
talking
about
our
our
our
draft.
There
are
a
number
of
items
that
we
know
we
want
to
talk
about.
There
are
a
few
items
that
we
think
we
want
to
talk
about
and,
depending
on
how
our
our
time
goes,
we
may
be
able
to
open
the
floor
for
things.
B
People
are
really
want
to
talk
about,
but
we'll
we'll
be
okay.
Yes,
it's
friday.
For
some
of
you,
I
I
very
much
appreciate
the
fact
that
it
is
friday
for
some
of
you
all
right.
As
you
know,
model
oo
I
itf
iad
rfc
modelo
has
been
posted
and
there
has
been
a
lot
of
list
traffic.
B
Thank
you
all
very
much
for
participating.
We've
made
a
lot
of
progress
on
on
this.
These
are
the
issues
that
we
we
thought
that
we
would
start
with,
seeing
how
far
we
can
get
on
them,
and
so,
let's,
let's
go
in.
We
have
been
discussing
on
the
list.
The
roles
that
were
my
yeah
right
we
wanted,
we
want
to
deal
with
the
the
the
the
roles
for
the
rsc
that
need
to
be
reallocated
right
and
we've
talked
about
some
of
them.
B
The
website,
for
example,
has
been
discussed.
These
are
issues
62
and
61.,
and
there
was
there's
a
suggestion
that
we're
okay
on
issue
60.
As
long
as
we're
have
had
text.
That
looks
a
lot
like
what
we
have
for
issue
59.
B
So
the
floor
is
open
for
anyone
that
wants
to
discuss
any
any
of
the
open
issues,
any
any
of
the
62
and
61
things
or
anything
else
related
to
the
roles
played
by
the
rse.
C
B
A
C
B
B
Okay,
so
this
is
the
who,
who
escalates,
and
how
about
all
that
works.
C
Yeah,
I
think
this
one
already
has
consensus
actually
and
somehow
the
labels
got
lost,
but
people
can
open
up
a
new
issue
on
this.
B
Yeah,
I
I
I
don't
remember
any
further
open
issues
on
it.
I
think
we
were.
We
were
okay
with
rsab
handling
a
dispute.
Right
I
mean
it's
gonna
go
first
to
the
stream
and
stream
manager
by
themselves.
It's
just
that
that
if
that
doesn't
work
where
you
go,
where
do
you
go
and
there's
text.
B
B
All
right
so
sorry
that
we
spent
time
on
things
were
open.
Next
one
was
61.
or
60.
Yeah
60
is
open.
60
is
closed.
It's
61
and
62
that
we're
open
I've
said
street.
Dear
islam,
61.
C
So
here
we
have,
I
think,
some
proposal
there's
something
related.
Some
text
related
that
jay
put
out
about
doing
the
annual
report,
and
I
think
that
address
is
61..
Jay
is
that
was
that
your
intent?
D
Ahead,
so
we,
if
we're
not
explicitly
stating
that
it
is,
there's
been
a
shift
from
the
rsc
doing
it
to
the
rpt
doing
it.
But
in
the
text
I've
done.
The
rpg
is
now
responsible
for
implicitly
to
gathering
the
requirements
in
order
to
develop
its
work
plan.
B
D
The
the
text
peter
has
well
martin
durst,
had
some
major
issues
with
it
which
I've
replied
to
and
haven't
seen
anything
back
from
that
and
peter
said
andre
had
some
questions
about
it
with
one
about
the
level
of
detail
about
the
timing
of
how
those
things
are.
The
work
plan
is
developed,
which
I
think
is
a
excessive
level
of
detail
to
go
into
and
the
second
one,
more
importantly
about.
D
The
feedback
from
the
work
plan
and
how
that's
incorporated
or
not
incorporated,
which
is
a
quite
a
good
point,
and
one
that
I'd
sort
of
danced
around
a
little
bit
in
the
text,
and
so
that
needs
a
little
bit
more
work
on
that.
D
And
so
sorry
just
we
we're
using
the
words
work
program.
Just
as
the
specific
text
we're
putting
in
at
the
moment.
First.
B
Okay,
so
martin
durst,
anyone
else
want
to
talk
about
this
issue.
There
there
has
there's
text,
that's
been
proposed,
there
have
been
some
discussion
and
small
amounts
of
of
of
word
changes
on
some
of
it
is.
Are
we
to
the
point
where
we
think
peter
can
craft
the
final
text
based
on
the
on
the
email.
B
B
F
F
The
question
about
the
feedback
process
was
about
how
we're
going
to
set
expectations
regarding
with
the
community
regarding
how
that
feedback
process
was
going
to
go
on
the
work
program
that
the
rpc
would
put
forward
as
a
proposal,
and
then
how
would
that
get
finalized?
I
don't,
as
with
my
document,
editor
had
on-
I'm
not
quite
sure
how
to
craft
that
yet,
but
I
thought
it
would
be
worthy
to.
G
Yeah,
so
I'm
not
quite
sure
if
I
understand
the
term
work
program
here
entirely
and
if
we
really
need
it,
I,
I
guess
there's
a
different
thing
where
we,
where
the
lsc
evaluates
the
performance
right
so
that
would
not
be
based
on
the
work
program.
Work
program
is
probably
only
something
that
is
an
indication
to
the
community
what's
done,
but
that
should
be
quite
straightforward
from
my
point
of
view,
based
on
what
the
group
is
defining
and
doing-
or
maybe
my
understanding
is
wrong
here,.
E
D
A
Yet
yeah,
I'm
on
the
question
that
peter's
second
question
about
taking
feedback
under
advisement.
I
think
the
key
thing
there
is:
if
a
community
member
feels
they're
being
ignored,
would
they
raise
concerns
with
the
llc?
A
A
D
The
myriad
question
about
the
work
plan,
so
the
rpc
will
not
be
getting
its
sole
work
from
the
rswg
and
then
the
rsab.
D
Okay,
that's
where
bigger
things
will
come,
certainly,
but
it
gets
some
work
come
from
the
stream
managers,
for
example
the
the
recent
terminology,
discussions
and
work
has,
you
know,
been
a
stream
manager
thing
or
all
changes
to
the
way
that
erratas
are
handled
at
a
at
a
basic
level
of
the
the
isg
has
some
changes
about
the
way
that
the
isg
wants
to
handle
errata,
and
it
also
gets
it
from
authors
who
say
you
know,
could
you
please
do
this
differently?
Or
how
about
you
do
this?
D
It
gets
it
from
a
whole
variety
of
sources
and
that
all
needs
to
be
put
together
and
delivered.
And
for
me
the
point
about
a
work
program
is
that
that
is
then
transparent.
Everybody
gets
to
see
that
everybody
gets
to
understand
the
full
level
of
work
so
that
you
then
don't
have
people
asking
the
same
thing
over
and
over
again,
then
you,
you
understand
when
things
can
get
done
and
you
can
see
the
relative
priorities
of
those
things.
It's
just
a
it's
a
basic
management
mechanism.
D
So
that's
what
the
work
program
is
about
and
that's
why
it's
something
more
than
just
the
work
that
comes
from
the
group
and
and
secondly,
because
the
work
program
is
something
that
we
are
going
to.
D
If
we
define
a
work
program
as
existing
within
the
the
document
that
peter's
writing,
then
it
will
become
part
of
the
performance
targets
because,
by
definition
the
performance
targets
are,
you
must
deliver
what's
in
the
rscs,
and
so
the
performance
targets
will
include,
you
know
annually
or
whatever
it
is
producing
a
work
plan
commenting
on
it
and
other
things,
so
that
will
be
linked
in
that
way.
C
If
I
may,
I
just
want
to
capture
the
the
comment
that
lucy
made,
because
I
think
we
did
discuss
this
on
list
and
jay.
I
think
it's
pretty
relevant,
so
stick
around
for
a
second.
What
lucy
wrote
in
the
chat
was
there
needs
to
be
a
buck
stopper
for
this
activity.
The
group
as
a
whole
won't
be
a
good
channel
for
the
rpc,
so
the
the
question
is
what-
and
I
think
we
covered
this
a
little
bit.
C
What
is
the
flow
of
information
that
that
you
envision
for
for
feedback
in
this
process?
And
I
don't
know
if
we
cover
this
yet
in
the
draft
peter.
F
D
Just
on
this,
so
so
what
what
my
text
proposes
is
that
the
rpc
annually
produce
a
work,
draft
work
plan
and
consult
with
the
community
on
that
with
the
broader
community
on
it,
and
that
is
the
mechanism
for
feedback
to
come
through
on
that,
and
we
can
have
that
more
often
than
annually
if
required,
and
so
so
and
the
the
buck
stop
it
well.
Ultimately,
the
rpc
needs
to
listen
to
that
and
deliver
it,
and
the
llc
is
the
enforcer
to
ensure
that
they
have
done
that.
D
If
people
are,
you
know
or
the
escalation
path
for
people
are
concerned,
that
they
haven't
done,
that
which
I
suspect
is
going
to
be
a
never
used
role.
But
that's
you
know
it's
there
in
case.
We
need
it.
G
I
wanted
to
reply
to
jay
again.
Thank
you.
Thank
you
for
explaining
that
that
makes
it
clear
to
me,
but
I'm
I'm
not
sure.
If
we
need
this
level
of
detail
in
the
draft,
I
think
what
we
agreed
previously
is
that
we
need
a
way
for
the
rpc
to
report
back,
and
you
know,
having
a
plan
is
also
a
little
bit
explaining
what
you
plan
to
do,
rather
than
just
reporting
on
what
you
did.
G
That's
fine,
but
I
think
the
part
that
we
need
to
cover
in
the
draft
is
that
they
need
a
certain
level
of
communication
and
transparency,
and
I
don't
think
we
need
to
talk
about
a
work
plan
there
or
even
like
the
recurrence
of
the
work
plan,
how
often
that's
done
or
how
the
attribute
or
whatever
that
seems
to
be
more
detailed
than
need
to
be
specified.
G
H
The
process
that
jay
is
describing
would
work
well
for
simple
issues
like
like
a
request
for
change
in
how
errata
are
handled
from
the
iesg.
H
I
think,
if
you
take
the
label
labeling
discussion
from
yesterday
and
think
about
how
that
affects
all
of
the
streams
and
the
need
to
coordinate
that
across
tools
across
publishing
specifications
across
llc
budgets
across
tasks
for
the
rpc,
it
gets
a
lot
more
complicated
and
and
that
there,
as
mira,
says
there
are
feedbacks
involved
there
that
I
don't
think
this
process
handles.
Well,
I
think
you
end
up
fractured.
D
Can
I
come
to
those
thanks,
so
the
in
the
text
that
I've
proposed
one
of
the
things
that
the
rfpc
is
expected
to
do
through
with
advice
from
the
rsab
is
decide
on
any
requirement
given
to
it
whether
it
can
say
actually,
no,
that's
too
big
a
requirement
for
us
that
has
to
go
back
to
the
community
process.
D
I
the
rswg
and
through
that
process,
to
do
that,
and
that
is
the
point
at
which
the
things
that
you've
described
lucy,
I
think,
should
be
resolved
and
if,
if
they
can't
be
resolved,
then
that's
because
we
that's
a
an
issue
with
the
rswg
process.
We
need
to
deal
with
not
an
issue
with
the
rpc,
which
I
think
you
know
is
the
implementer
not
the
place
of
which
those
things
are
resolved
and
then
separately
to.
D
It's
not
currently
in
the
draft
notes
in
my
proposed
text.
Is
that,
though,
which
is.
H
F
D
Well,
that's
that's
what
I
think
is
addressed
in
the
draft
by
if
the
the
rpc
says.
No,
we
can't
implement
that.
That's
too
big,
then
that
becomes
that
whoever
is
proposing
that
has
to
go
through
the
rswg
process
and
the
anything
that
goes
through
the
rswg
process.
That
comes
out
of
that
the
rpc
simply
has
to
implement.
There's
no.
The
rpc
is
not
in
a
position
to
say
no
to
that,
so
that
that's
the
mechanism.
H
D
Okay,
I'm
struggling
to
understand
that,
because
that
that
that
becomes
a,
and
so
are
you
saying
that
an
output
of
the
rswg
could
still
have
this
problem
of
how
to
coordinate
it
across
multiple
things.
H
I
think
that's
correct,
I.
I
am
concerned
that
we're
going
to
get
into
an
iterative
process
here
that
echoes
forever
and
gets
hung
up
on
things
like
funding
requirements
or
amount
of
time
available
from
the
tools
team
or
whatever
you're
going
to
have
competing
requirements
and
not
a
clear
mechanism
for
resolution.
B
H
That's
exactly
correct.
I
I
unfunded
mandate
and
right
buy
in
from
the
community
on
a
set
of
work
done
in
the
work
program
that
then
doesn't
have
a
path
for
execution
somewhere.
There
has
to
be
a
driver
for
this,
so
I'm
just
saying.
D
Yeah
yeah,
sorry
mike.
So
if,
if
the
rsgwg
put
something
forward
which
the
rpc
says
within
our
current
resources,
we
can't
deliver
that
that
then
becomes
an
llc
problem.
The
because
the
llc
is
obliged
to
implement
the
things
that
the
rswg
puts
forward.
In
the
same
way,
we're
obliged
to
implement
anything
that
you
know
any
any
other
rfc
that
is
produced
we're
obliged
to
implement
the
that
instructs
us
in
that
way,
the
only
backstop
being
that
we
can't
be
bankrupt
and
that's
you
know,
an
extreme
hypothetical.
D
I
The
the
deal
is
that
we
keep
forgetting.
There
are
lots
of
different
cycles
in
this
process.
I
mentioned
it
in
the
tech
in
chat
room,
but
doing
the
rfcs
only
starts
the
process
of
getting
it
implemented.
I
Then
there
may
be
either
a
contract
change
or
a
task
order
change
to
actually
get
the
rpc
to
do
something,
and
so,
with
respect
to
with
respect
to
this,
I
would
expect
the
llc
to
push
back
at
as
part
of
as
as
part
of
this
liaison
thing
to
the
issuance
of
the
original
rrc.
I
If
it's
not
going
to
be
fundable
or
to
explain
when
it
can
be
funded
based
on
on
what
it
knows,
and
I
would
expect
that
the
llc
would
be
upfront
about
yeah
you're
telling
us
to
do
this,
but
it
makes
no
sense
and
it's
not
cost
effective,
so
it'll
get
added
to
the
contract
at
some
point,
but
it's
going
to
cost
us
an
opportunity
for
everything
else
that
you
want
to
do
so,
maybe
maybe
what
we
need
for
the
rfcs
coming
through.
I
This
is
an
llc
consideration,
section
that
basically
says
here's
what
it's
going
to
cost
and
here's
how
it
and
here's
what
we
can
implement
lucy
would
that
sort
of
work
for
dealing
with
some
of
this.
B
H
C
H
C
Yeah
I
just
if
I'm
a
make
one
clarification
jump
in
the
queue
for
a
moment.
I
think
there
are
two
different
processes
that
we're
talking
about.
The
first
process
is
the
rfc
process,
and
mike
was
talking
about
having
an
llc
consideration
section.
C
The
second
process
is
the
the
work
program
and
I'm
not
quite
sure,
I'm
not
I'm
not
quite
sure
if
we've
covered
that
that
that
cycle,
so
my
my
suggestion
would
be
that
we
separate
out
these
issues
that
jay,
as
you
review
your
text,
that
you
propose
one
of
the
things
I've
added
into
the
the
the
issue
here
is
that
that
is
a
suggestion
from
myria,
which
I
think
is
a
good
one,
and
it's
a
little
bit
of
work
for
peter,
though,
which
is
a
process
diagram.
C
C
B
Do
people
think
we're
converging
on
on
on
solutions?
I
I
we
don't
need
to
wordsmith
the
exact
text,
but
it
seems
like
we're
heading
in
a
direction
that
we
can
have
some
proposed
text
and
see
whether
we
agree
with
it
is
that
is.
Is
there
do
we
do?
We
think
we're
getting
there?
I
mean
I
I
think
jay
is
getting.
That
text
is
getting
there
and
we
need
to
add
it
and
we've
got
some
suggestions
like
the
implementation
plan.
Notion
or
you
know,
llc
considerations
gives
they
they're.
They
will
observe
right.
B
I
mean
they're
not
going
to
be
surprised
by
any
of
this
stuff
and
as
jay
points
out
this
cycle
of
funding
and
the
you
know,
feasibility
and
its
effect
on
other
groups
and
money
is
hits
us
all
over
the
place
in
other
places.
You
know,
data
tracker
work,
reorganization
of
how
you
know
pieces
work.
I
mean
we,
we
encounter
this
specific
problem
often
and
we
manage
to
get
through
it
because
people
are
are
aware
of
what's
going
on
and
we
you
know
they
we
get
feedback.
So
I
I
think
it's
all
right.
B
E
There
we
go
yeah,
I'm
sorry,
this
thing's
too
slow.
I
think
this
is
entirely
reasonable.
I
I
think
that
the
text
that
jay
has
produced
is
is
a
good
start
toward
this.
I
think
mike's
suggestion
that
we
deliberately
include
some
sort
of
rules
in
here
that
say
that
the
llc's
feedback
on
how
things
are
prioritized
is
an
explicit
part
of
the
the
documents
that
are
produced
and
that
may
be
in
in
a
lot
of
cases
trivial,
but
for
the
big
things
that
lucy's
concerned
about.
E
Yes,
I
think
it's
going
to
be
a
critical
part
of
the
decision-making
process
that
the
working
group
follows
and-
and
it
can't
just
be,
oh,
you
need
another
check
in
that
in
the
process.
No,
I
think
it's
going
to
have
to
be
that
if
someone's
going
to
ask
for
everything
to
be
much
much
more
expensive,
then
then
all
of
those
things
and
the
resources
need
to
be
worked
out
as
as
part
of
the
discussion
and
not
just
as
an
afterthought.
B
All
right,
I
think
we're
does
anyone
have
any
other
thoughts
that
we
haven't
surfaced
on
this
item
on
this
on
this
issue,.
B
And
mary,
I
I
take
your
point
that
we're
the
the
this.
This
thing
is
somewhat
bigger
than
this
specific
issue,
but
I
think
the
solutions
were
coming
about
coming
up
with
seem
to
address
the
larger
issue
rather
than
the
specific
one
here.
F
That
sounds
good.
I
think
I
have
what
I
need
to
craft
some
text.
I
think
it's
not
just
the
expense,
but
it
could
be
skill
sets.
It
could
be.
D
F
Know
things
that
are
that
need
to
be
factors
that
need
to
be
taken
into
account
from
an
implementation
standpoint
as
martin
puts
it.
So
I
think
I
have
what
I
need
to
try
to
draft
some
and
improve.
You
know
add
to
what
jay
has
done,
which
I
think
is
a
good
start
great.
B
And
I
think
again,
jay
had
proposed
some
text
here,
I'm
right.
If
I'm
remembering
correct
any
anybody.
Wanna
talk
about
this.
D
I'll
intro
it
briefly,
then.
So
this
is
the
the
work
program,
and
this
is
the
annual
publication
on
the
on
the
work
program
which
I,
in
response
to
mary's
point
earlier
about
why
it's
necessary.
It's
because
I
think
this
is
an
important
transparency
step
that
we
should
maintain,
and
the
feedback
step
is
an
important
part
within
it.
Noting,
of
course,
that
more
work
is
needed
in
the
text
about
the
feedback
step,
in
particular,
as
peter
said
about
setting
expectations
of
what
can
be
achieved
during
that
feedback
step.
B
G
Yes,
so
my
concern
is
not
about
implementing
this
process
as
proposed,
which
is
like.
I
don't
think
we
need
to
put
all
the
details
into
the
rc.
The
important
part
is
that
is
to
have
transparency
and
feedback,
and
that's
what
we
should
write
in
the
rfc.
If
you
want
to
implement
it
with
a
work
plan
that
then
goes
out
once
a
year
or
whatever,
and
and
gets
community
feedback,
and
so
on.
That's
a
good
thing.
But
if
you
want
to
change
that
in
future,
then
you
don't
have
to
change
the
rfc.
B
E
E
I
think
it's
important
enough
here
that
having
it
in
the
rfc
even
at
a
very
high
level,
which
is
all
jay
has
really
done,
is
sufficient,
and
maybe
we
do
some
make
some
small
concessions
and
make
remove,
say
the
the
reporting
periods
and
and
don't
specify
that
and
just
say
that
they
will
regularly
produce
reports
and
produce
a
work
program,
and
that
will
allow
that
to
be
adjusted
so
that
it
might
be
every
two
years
instead
of
one
year
and
that
sort
of
thing,
but
in
general
I
think
this
is
important
enough
to
have
written
down.
J
Sorry
to
open
my
mouth
right
now,
but
I
guess
I'm
gonna
do
it.
It
seems
to
me
that
we
are
going
rapidly
down
a
path
of
turning
these
functions
into
lsc
functions
rather
than
functions
which
are
managed
in
an
independent
way.
That
may
be
a
pretty
good
idea.
It
may
be
a
realistic
idea,
but
if
that's
where
we're
going
and
that's
where
the
critical
path
decisions
are
going
to
be
made,
then
we
are
spending
an
awful
lot.
J
I'm
worried
about
details
which
may
not
make
any
difference
and
for
the
record,
if
there's
any
expectation
that
somebody
with
even
mild
vision
problems
even
on
very
large
screens
of
media,
those
spread
across
both
screens
can
read.
What's
going
on
in
the
slide
area
right
now,
I
have
this
for
you.
B
J
Well,
it's
it
it's
why
I
posted
that
rant
weeks
ago.
Yes,
yeah,
I
I
I
don't
know
I
I
think
we
made
this
path,
maybe
inexorable,
but
if
it
is
inexorable
and
we
don't
have
alternatives,
then
the
sooner
we
recognize
that
and
change
the
process
of
how
we're
trying
to
do
this.
To
recognize
that
the
last
time
we
voiced
on
it.
B
This
rfc
may
contain
a
number
of
glaring
errors
that
when
we
actually
implement
it,
show
up
very
quickly
and
we
have
processes
to
fix
it,
and
we
have
in
this
particular
case
a
working
group
and
they
can
go
and
obsolete
whatever
rfc
comes
out
of
this
and
fix
it.
B
J
The
working
group,
especially
and-
and
that
makes
me
very
nervous
because
if
we're
gonna
have
a
publication
process
which
is
run
by
people,
don't
know
what
they're
doing
then,
if
problems
develop,
it
is
not
clear
that
we
have
a
way
to
remedy
that
in
the
same
fashion,
which
we
have
ways
to
remedy
a.
The
idea
puts
out
a
piece
of
protocol
work
and
it
doesn't
work,
and
we
understand
it's
an
engineering
group
why
it
doesn't
work
when
you
go
up
and
do
something
about
that.
J
But
again
ignore
me
and
go
back
to
what
you
were
doing.
A
C
C
Okay,
yeah,
I
my
airpods,
didn't
take
over
the
microphone
when
I
thought
they
did
so
that's
why
that
was
the
resolution.
I
think
we
have
on
this
one,
if
I
understand
correctly,
is
text
needed,
which
is
the
same
text
that
it's
at
the
same
textual
update
for
issue,
61.
C
they're
they're,
covered
by
the
the
same
text.
If
I
understand
correctly
jay
and
peter,
is
that
your
understanding
as
well
just
to
be
clear.
F
Yeah,
I
I
think
they
sort
of
are
bundled
together
there
and
if
I
have
questions
I
can,
I
might
ping
jay
on
or
off
list
to
craft
some
things
with
him.
And
then
you
know
propose
that
on
list
and
get
that
in
the
draft.
F
B
B
All
right,
so,
the
next
item
that
that
has
the
that's
the
first
line
on
our
our
issues
to
discuss
our
next
one
is
interaction
between
rswg
and
rsab
policies
and
rpc
llc
projects.
So
these
are
issues
57
and
what
did
I
do
57
and
56.?
So
let's
look
at
56.
First.
D
Right,
so
if
I
can
intro
this
again,
this
is
addressed
by
the
text
about
the
work
program.
Sorry,
which
one
are
we
on.
Are
we
on
the
process
of
work
all
right?
Sorry,
so,
there's
already
a
well.
The
text
says
that
the
rpc
has
to
make
a
decision
about
whether
or
not
it
can
implement
something
without
consensus
or
whether
something
needs
to
go
to
consensus.
D
I
can't
see
no
other
way
other
than
having
the
rpc
make
that
determination,
unless
you
want
to
specifically
create
that
as
a
role
for
the
rsab.
It
was
a
role
previously
for
the
rse,
but
it
can't
be
a
role
for
the
rs
ea
in
this
situation.
In
this
setup
here
jay,
I.
C
Hate
to
interrupt
you,
but
this
week
as
it,
I
think
this
issue
we've
resolved
and
that
there's
text
and
then
it's
closed
yeah
right.
So
I,
if,
unless
brian
you
see
it
differently
or
peter,
you
see
it
differently.
I
suggest
we
move
on.
C
Oh,
no,
it's
even
reopened,
I'm
sorry,
it's
been
reopened
but
yeah,
but
I
think
the
text
here
what
we
said
right
was
I
at
the
end
of
the
day
this
this
had
to
do
with.
If
there
was
ambiguity
with
the
with
policy
in
terms
of
the
freedom
of
the
rpc,
to
act,
that
the
rpc
would
bring
the
matter
to
the
rsab.
Who
will
interpret
that
policy
and
jay?
Did
you
cover
that
in
your
new
text?
I
didn't
think
you
did,
but
no.
C
C
C
F
C
B
D
I
C
If
I'm
I'm
gonna
try
and
interpret
jay's
answer
here,
let
me
see
if
I
get
you
right,
jason,
that
I,
if
I'm
understanding
the
response
here
right,
the
response
to
that
is
the
work
program
is
published
annually,
the
as
part
of
this.
If
the
the
the
community
then
provides
feedback
on
that
work
program
and
then
there's
this
step
in
which
that
that
is,
the
the
comments
from
the
community
are
resolved,
and
the
question
is
who
owns
that
that
resolution
step?
C
Is
there
any
recourse
through
the
through
the
rswg
or
rsap,
and
I
think
the
answer
to
that
was
no,
but
jay
now
you'll
tell
me
I'm
wrong
or
it's
undecided.
B
B
E
E
E
I
think
that's
reasonable
and
at
the
point
that
the
working
group
does
have
a
have
a
consensus
resolution
that
is
documented
that
should
be
answered
directly,
but
when
it
comes
to
feedback,
I
think
the
expectation
would
be
that
the
rpc
simply
takes
that
feedback
on
in
the
usual
fashion.
It
reads:
the
email
maybe
responds
to
the
email
in
a
professional
manner,
and
that
is
the
end
of
it,
and
if
people
have
problems
with
that,
they
can
go
to
the
llc.
I
F
D
Yeah
so,
for
example,
if
one
of
the
stream
managers
wants
errata
handled
differently
for
that
stream,
then
that
requires
rpc
to
change
their
tooling
around
that
kind
of
thing.
If,
if
an
author
comes
up
with
a
a
good
suggestion
about
something
that
would
improve
the
rpc
processes
and
do
something
differently,
if
there's
a
requirement
for
an
experiment
such
as
it's
the
auth
48
in
github
experiment,
then
there
are
a
variety
of
things
there
that
are
don't
need
to
go
through.
A
consensus
process
are
smaller
than
a
consensus
process.
G
Every
time
I
try
to
use
my
audio
now,
I'm
actually
more
worried,
because
you
know
that
are
kind
of
operational
things
and
when
you
put
it
in
the
work
plan
and
then
send
out
the
work
plan
for
community
review
and
ask
input,
then
you
will
get
a
lot
of
input
on
all
of
these.
G
Like
nitty
gritty,
small
things
which
I
think
is
completely
unnecessary,
I
mean,
I
think
we
want
transparency,
want
to
know
what
the
rpc
is
doing
and
we
want
somebody
to
advise
the
rpc
who
has
some
kind
of
idea
about
what
the
community
wants.
But
I
don't
wouldn't
want
to
discuss
all
these
small
things
with
the
community
in
detail.
G
No,
I'm
not
saying
secret
deals,
I'm
just
saying
you
know
somebody
has
to
take
his
decision
and
we
move
on.
We
don't
have
to
discuss
everything
to
the
to
the
total
end
and,
of
course
we
need
transparency.
We
need
to
document
these
things
similar,
as
we
have
like
minutes
for
all
kind
of
meetings,
and
people
can
look
up
what
happened
but
trying
to
discuss
every
tiny
little
discussion
with
the
community
can
just
like
end
in
in
chaos.
B
G
That
you
have
the
work
plan
to
send
it
out
to
the
community
in
order
to
get
feedback
about
the
work
plan.
Right
and
maybe
it's
me,
who's
still,
not
understanding
what
kind
of
level
of
detail
we
want
to
put
in
the
work
plan.
But
as
long
as
I
don't
have
an
understanding
what
this
work
plan
actually
is
I'm
worried
about
putting
specifying
it
in
the
rc.
C
Here,
if
I
may,
miriam
is
you're
concerned
about
the
work
plan
going
too
detailed
and
I'd
say
I'd
suggest
a
little
operational
practice
will
get
us
over.com,
but.
E
Martin
expectations
about
how
this
process
is
going
to
work
is
probably
the
the
sensible
way
out
of
this,
like,
as
you
say,
elliot,
there
are
probably
some
operational
practices
that
that
things
will
fall
into
that
will
ensure
that
this
will
work
smoothly.
I
can't
imagine
people
nitpicking
things,
but
in
the
past
the
rpc
has
made
public
it's
its
plans
on
various
things.
I
know
that
we
publicly
talked
about
the
auth
48
github
thing
that
the
j
talk
mentioned
and
that's
fine.
B
It
it,
it
seems
to
me
that
there's
no
text
and
no
suggestion
that
the
that
either
the
rswg
or
the
rsav
approves
the
work
plan.
We
just
get
it
and
note
that
it
includes
the
items
we
want.
It
might
have
things
that
we
don't
care
about,
but
there's
no
approval.
There's
no
there's
no
official
discussion
of
the
work
plan,
there's
just
notice
of
the
work
plan.
I
don't
think
we
have
any
more
than
that.
G
And
so
that's
not
what
I
really
understood
right,
because
there
was
the
idea
about
getting
feedback
about
the
work
plan
and
I'm
also
I'm
not
suggesting
to
like
hiding
doing
something
and
hiding
that
right.
It's
it's
very
good
to
be
open
everything.
The
rpc
is
doing
it's
just
like
who
decides
about
what
the
rpc
is
doing.
That's
the
question
that
I
don't
want
to
have
like
the
whole
community
deciding
about
everything
and
they
brought
up
the
example
of
the
narrator
process
right.
G
We
changed
the
era
to
process
slightly
so
that
the
rpc
is
now
processing
editorial
error
just
directly
instead
of
the
80s
doing
it.
So
that's
really
something
between
the
workflow
between
the
80s
and
the
rpc
and
it's
you
know
if
somebody's
interested,
it's
documented
in
various
minutes,
I
guess,
but
it's
like
not
super
exciting
for
the
community
as
a
whole
and
involving
more
people
than
those
which
are
actually
affected
directly
is
probably
not
helpful.
B
Okay,
we
might
want
to
let
peter
and
jay
do
what
they
said.
They
would
do
on
the
last
couple
ones,
which
is
edit
the
text
that
exists
and
then
see
whether
it
it
does
what
we
want,
because
I
think
we're
multiple
people
are
reading
different
things
into.
What's
already
there
and
the
email
discussion,
jay.
G
Definitely
thanks.
I,
I
think
my
my
main
problems.
Really.
I
don't
understand
what
people
think
what
this
work
plan
is.
So
that's
the
problem
here.
D
D
I
believe
as
a
concern,
and
so
that's
why
there
isn't
that
level
of
approval
in
there
anymore,
because
we
had
a
discussion
and
there
seemed
to
be
no
other
place
that
that
level
of
approval
could
go
to,
and
I
also
raised
the
concern
that
that
meant
that
there
is
to
a
degree
a
de
facto
approval
step
of
the
llc,
because
it
approves
the
resources
within
it
and
things
and
improves
you
know.
Have
people
followed
the
process
correctly
right.
So
that's
why
we're
at
the
position
we're
at
which
to
me
is
slightly
sub-optimal.
D
I
would
have
preferred
the
rsab
to
do
it,
but
it
works
nonetheless,
and
secondly,
to
meria's
point.
The
reason
that
we
have
to
put
something
like
the
errata
changes
into
a
work
plan
into
a
single
document
is
so
that
people
are
aware
that
this
is
the
full
set
of
changes
to
the
steady
state
machine
that
the
rpc
will
be
making,
and
this
is
how
they
are
prioritized
against
each
other.
D
This
is
the
resources
that
are
required
and
therefore
this
is
the
total
set
of
resources
asking
people
to
go
to
read,
minutes
here
or
bits
there
or
do
that
sort
of
stuff
to
me
is
unreasonable.
You
know
we
need
that
level
of
transparency,
for
what
is
a
very
expensive,
very
important
part
of
the
organization.
G
About
approval,
it's
not
fully
to
me
like
what
the
full
purpose
about
this
work
plan
is,
if
there's
no
chance
to
influence
a
work
plan
from
anybody
in
the
community
right.
So
if,
if
the
community
has
an
idea
idea
about
what
should
happen
next
and
then
the
rpc
comes
up
with
a
totally
different
work
plan.
What
happens
in
that
situation?.
D
It
goes
to
the
community
feedback
process
and
if
people
disagree
with
that,
and
the
rpc
sticks
to
its
guns
and
it's
escalated
to
the
llc-
we've
specifically
ruled
out
any
other
mechanism
for
that
to
be
addressed.
G
Yeah,
I'm
kind
of
I'm
still
questioning
the
point.
If
you
know,
if
you
need
to
have
this
kind
of
plan
or
if
it's
rather
something
on
a
case-by-case
basis,
but
anyway,
I
wait
for
your
text,
so
my
my
second
question
is
then
about
this
example
again
right,
because
this
error
processing
was
something
that
was
discussed
in
the
isg
and
then
like
implemented
by
the
rpc
on
a
basically
quite
short
notice
like
within
a
few
weeks.
So
it's
not
something
that
would
go
from
my
point
of
view
in
a
yearly
work
plan.
B
G
So
I'm
I'm,
I
know
I'm
repeating
myself,
but
I
make
I
make
my
point
once
again.
I
think,
with
all
these
questions
about
how
I
don't
understand
how
this
work
plan
works,
I
think
we
should
not
specify
it
on
this
level
of
detail
university.
It's
fine!
If
we
do
all
that
right,
but
if
I
don't
understand
what
it
means
and
we
write
it
down,
then
I
think
we
have
a
problem.
B
Again,
I'm
going
to
suggest
that
we
let
peter
and
jay
work
out
the
the
changes
to
the
text
that
was
proposed
and
see
whether
that
addresses
the
issues.
They've
heard
this
discussion-
and
I
think
you
know
less-
is
better
for
some
of
the
stuff,
not
tying
the
rpc's
hands
or
the
llc's
hands.
F
Yeah
with
my
with
my
editor
hat
on,
I
think
that
first
of
all,
this
has
been
a
good
discussion.
I
think
we
have
a
sense
of
what
needs
to
get
clarified,
or
I
do
just
to
put
a
finer
point
on
it
with
meridia.
There
are
things
that
are
currently
specified
that
the
rse
was
doing
under
the
second
version
of
the
rfc
editor
model
that
would
fall
through
the
cracks.
F
If
we
didn't
say
something
along
these
lines,
I
think
we
should
keep
it
high
level
and
not
go
into
too
much
detail,
but
taking
martin's
feedback
into
account.
I
don't
think
we
can
be
so
high
level
that
we
just
say
there's
a
report
once
in
a
while.
I
think
it's
got
to
have
a
little
bit
better
defined
process
so
that
folks
have
a
comfort
level
that
things
will
be
addressed
in
in
a
transparent
way.
That
is
understandable,
as
opposed
to
just
leaving
all
those
details.
Undefined.
B
F
So
so
oops
sorry,
you
know,
let's,
let's
we'll
try
to
work
this
into
the
text.
The
next
version
of
the
document,
which
hopefully
we'll
have
out
in
a
week
or
two-
you
know
we'll-
have
better
definition
around
this
and
then
we
can
talk
about
this
on
list
or
at
the
next
interim
call.
B
Okay,
this
also
is
a
is
the
break
time
we're
coming
up
on
the
break,
that's
good,
because
we're
going
to
go
into
another
item.
The
next
item
to
discuss
is
rca
higher
fire
management,
so
we'll
pick
that
up
after
the
break
any
anything
before
we
get
take.
Take
the
break.
B
C
For
those
listening
note
that
we
have
to
change
rooms,
there's
a
new
meet
echo
room,
so
you
should
close
out
from
this
room
and
go
to
the
next
one.