►
From YouTube: IETF115-RSAB-20221107-1130
Description
RSAB meeting session at IETF115
2022/11/07 1130
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
A
Hello,
everybody.
Let's
start,
as
we
said,
we
don't
have
a
very
crowded
agenda,
but
we
have
a
few
topics
and
let's
try
to
get
to
it.
So
we
have
this
first
part
of
the
agenda,
which
is
more
our
administrative
part.
Cindy.
Do
you
want
to
take
that
yeah
and
then,
like
the
second
part,
will
we
will
hand
over
to
the
RPC
basically
and
running
through
a
couple
of
discussions
here.
D
D
D
D
F
I'm,
pretty
sure
I've
met
all
of
you
already,
but
my
name
is
Alexis
Rossi
and
I've
started
about
two
months
ago.
I
feel
like
I'm
still
trying
to
learn
all
of
the
vocabulary,
but
I
had
it
before
this
meeting.
I'm
not
gonna
lie
and
then
I
came
to
the
meetings
here
in
London
realized.
I
still
don't
know
all
the
vocabulary
so.
F
Anyway,
right
now,
what
I'm,
mainly
working
on
is
the
RFC
editor.org
revamp
with
torchbox.
If
you
have
any
input
you'd
like
to
give
me
on
that,
I
would
love
to
hear
it.
F
I've
been
working
on
making
sure
that
all
of
our
archiving
Partners
have
full
copies
of
the
rfcs
and
starting
to
work
on
getting
our
outlinks
from
rfcs,
and
things
like
that,
actually
archived,
so
that
we
have
completeness
in
our
Archive
of
stuff.
So
those
are
kinds
of
my
my
things
at
the
moment
and,
please
feel
free
to
come,
say
hi
to
me.
If
we
haven't
met
already.
D
Okay,
then,
the
next
thing
we
had
on
the
agenda
is
a
tooling
update
from
Robert
Sparks,
who
is
joining
us.
H
We
have
ourselves
related
and
editorial
stream
related
work
that
needs
to
be
done
in
xmlrc
and
data
tracker.
These
are
queued
for
probably
December,
beginning
of
January.
We're
not
expecting
anything
is
going
to
try
to
come
through
the
stream
before
then
don't
see
any
difficulties,
anything
is
likely
to
become
a
blocking
Point.
It's
just
a
matter
of
of
slotting
in
the
work.
A
C
A
As
I
said,
we
don't
have
a
lot
of
stuff,
but
we
don't
have
any
documents,
which
is
our
main
purpose,
so
that
was
the
first
part
of
the
agenda
and
I'm
basically
just
heading
over
to
the
apostino.
F
Okay,
so
actually
this
first
one
is
I,
don't
think
we
own
it
so
I
probably
put
it
in
the
wrong
place.
I
think
Lara's
raised
the
issue
about
rswg.org
and
and
if
there's
anything,
that
the
working
group
wants
to.
C
Do
I
just
registered
it,
rsap.org
was
taken,
but
that
one
wasn't
and
then
and
so
I
haven't
and
I
might
have
even
assigned
it
over
to
record
I.
Don't
know
I
can't
remember
but
sort
of.
If
it's
there
for
somebody
to
do
something
with
it.
We
have
it
right
and
we
probably
I,
don't
know
who
should
own
it.
It's
the
trust
or
whatever,
but
it's
available.
F
E
F
Okay,
so
the
next
one
was
for
the
headers
and
boilerplate,
and
it
was
just
to
check
whether
there
were
any
objections
to
the
proposed
path
forward
and
it
was,
namely
the
RPC
would
be
in
charge
of
headers
and
boilerplate
material
and
moving
the
page
that
the
IAB
has
on
their
website
to
the
rpcs.
The
RFC
editor
website
wondering,
if
there's
any
objections
to
that.
C
So
remind
me:
what
do
you
mean
by
in
charge
of
or
I
think
that's
a
word
serious,
but
so
so
it
basically
maintains
the
site
or
is
responsible
for
the
content,
because
I
think
the
streams
can
decide
their
own
boilerplate
right.
But
it's
basically
you
would.
You
would
host
the
the
content
and
and
basically
the
streams
or
the
RSM
or
the
rswg
would
instruct
changes
to
be
made
correct.
We.
F
Would
just
maintain
the
the
the
term
the
outcome
of
what
the
streams.
C
We
should
probably
have
this
little
bit
of
a
description
about
how
changes
technically
get
proposed
and
get
approved
right,
because
I
think
some
of
the
boilerplate
is
shared
across
all
the
streams,
and
that
would
be
an
rswg
rset
thing
and
some
of
the
polo
plate
is
per
stream
and
that
would
be
under
the
Stream
approving
bodies,
control
I.
Think
it's
a
terminology
right:
okay,
yes,
so
so
the
irtf
could
change
their
part
of
the
boilerplate,
but
not
the
shared
part.
The
SharePoint
would
need
to
have
agreement
across
the
streams
yeah.
C
I
hope
this
might
already
be
in
in
the
rfcs
that
create
the
streams
right
and
I,
don't
know,
but
it
if
it
does,
it
might
just
be
worthwhile
putting
that,
maybe
in
a
in
a
little
box
and
and
point
to
those
documents.
If
we
find
that
that
this,
what
I
just
outlined.
C
B
Lars
Memphis
Elliot,
section
3.2.6
of
RFC
9280
covers
boilerplates
and
the
process
for
updating
them,
so
I'm
not
quite
sure
what
you're
proposing
that
would
be
either
inline
or
differ
from
that.
But
I
think
how
the
you
know.
What
happens
within
the
streams
is
up
to
the
streams
to
decide
in
terms
of
their
own
approval
process,
I
gather
and
then
it
goes
through.
The
rsab
has
to
approve
something
and
then
there's
the
RPC.
That
has
a
role
and
then
the
ietf
has
it.
C
Absolutely
so,
if
we
I
couldn't
recall
that
we
said
that
if
we
say
that
so
I
don't
know
if
it
was
anything
more
or
different
than
what's
in
the
document,
I
wasn't
remembering
that
we
had
put
that
in
the
document.
So
then
we
just
basically
pointed
to
that
section
of
9280
and
we're
done
on.
E
A
F
The
next
one
was
just
a
reminder
that
we
created
the
arpet
I,
didn't
see
any
major
objections,
so
I
don't
think,
there's
much
to
discuss
unless
any
of
you
wanted
to
to
say
anything
I,
don't
think
I
heard
from
everyone,
so
I
just
wanted
to
make
sure.
A
No
concern
I'm,
just
like
the
the
description
you
have
of
the
proof
is
very
like
General
and
like
when
we
had
like
a
little
bit
of
a
discussion
about
this,
so
I
think
what
we
really
need
to
figure
out
is
to
find
the
right
boundary
like
we
have
to
discuss
what
and
that
probably
just
need
experience.
So
if
you,
if
you
just
keep
us
up
to
date,
was
about
her
experience
like
where
the
split
is
and
how
it
should
work
and
how
it
works
for
you,
I
think
that's
important.
F
Okay
right
we're
trying
to
do
the
right
thing,
so
our
goal
is
hopefully
to
have.
You
know
also
to
get
input
from
our
pet
about
what
needs
wider
discussion
and
what
doesn't
and
keep
you
apprised
of
what's
happening
and
also
the
list
archives
are
open
right.
So
anyone
can
see
what's
happening
there
and
and
provide
input
that
you
know
they
think
it
needs
to
be
discussed
elsewhere.
A
So
I
think
that
one
bad
outcome
would
be
if,
like
we
end
up
discussing
all
topics
in
two
places
and
have
like
just
like
a
huge
amount
of
people
or
more
people,
are
needed
and
like
having
big
discussions
about
all
kinds
of
little
things.
That
would
be
the
worst
outcome.
So
that's
that's
what
we
should
avoid
yeah,
so.
F
The
the
list
is
open
as
far
as
archives,
but
people
can't
actually
who
are
not
numbers
of
the
list
cannot
discuss
it
there,
and
actually
that
was
a
discussion
point
we
had
had
with
Jay
and
within
that
team,
which
was
we
don't
want
it
to
be
another
discussion
area
for
the
whole
Community
right.
If
it's
going
to
be
a
public
discussion,
it
should
happen
in
a
public
forum.
So.
A
It
but
like
what
I,
what
I
kind
of
saw
last
time
already
is
that
you
had
like
a
topic
that
you
discussed
in
the
art
prep
and
then
you
brought
it
to
the
rsip
and
then,
like
all,
the
people
from
Rapid
were
still
involved
in
the
discussion,
and
then
it
came
to
rsip
and
then
maybe
arsip
decides
to
bring
it
to
rswg
and
then,
like
you
know,
you
just
like
get
more
and
more
people
in
maybe
a
small
discussion
involved
so
like
I
think
that's
that's
something
to
watch
out
for.
D
C
Mean
iPad
is
something
that's
internal
to
the
RPC
right
and
so
the
the
r,
the
rsap
and
the
rswg
shouldn't
really
ever
hear
from
the
r-pad,
because
they
talk
to
you
and
then
you
talk
to
like
us
right
and
and
if
you
create
this
team
internally,
that
that's
that's
your
call
and
totally
fine,
and
then
you
you
use
them
for
what
you
want
to
use
them
for,
but
it
doesn't
change
the
structure
at
all.
Right
and
I.
C
Think
if
you
think
about
it
that
way
right
then
then
there's
a
pretty
clear
line
and-
and
we
wouldn't
have
those
the
same
people
in
the
discussions
really.
F
So
the
next
one
was
about
the
use
of
you,
it's
a
it's
a
pretty
detailed,
XML
and-
and
some
of
you
have
already
heard
this-
but
I
wanted
to
share
it
with
all
of
this
dream
managers,
because
it'll
impact.
All
of
you
sorry
so
in
earlier
times,
non-ascii
characters
could
not
be
included
in
the
rfcs
unless
or
within
running
paragraph
text,
unless
the
you
notation,
the
U
element,
was
used
and
that
was
found
to
be
an
error.
F
7997
does
not
require
the
use
of
you
and
so
XML
to
RFC
has
been
updated
to
allow
non-ascii
characters
to
appear
within
t,
but
we
added
some
text
to
the
style
guide
that
specifies
if,
if
those
characters
are
required,
like
understanding
those
characters
is
required
for
protocol
operation,
then
they
should
be
spelled
out
right.
So
you
notation
should
be
included
and
we
are
hoping
that
the
stream
editors
will
help.
Look
at
that
as
you're.
Reviewing
the
documents
right
like
is
it
required
for
proper
protocol
operation?
C
Yeah
rehearsing
the
Sunday
discussion
a
little
bit,
so
we
probably
the
metal
item
for
us-
is
to
to
not
make
sure
that
we
duplicate
Sunday
items
with
this
group.
But
so
you
can
ask
the
street
managers
right,
but
for
the
isg
right
we
don't
review
the
XML,
and
so
we
people
look
at
the
HTML
or
the
text
rendering
typically
and
they
will
they.
They
might
spot
a
Unicode
character
that
that
doesn't
have
the
parentheses
uppercase
expansion
in
it
and
they
might
flag
it.
C
But
since
we're
not
looking
at
the
XML,
we
I
guarantee,
you
will
not
find
things
and
I
also
guarantee
you.
It
won't
be
a
priority
for
ads
when
they
do
reviews.
So
it's
really
you
guys
that
need
to
be
because
really.
E
C
The
only
ones
other
than
the
authors
and
or
even
most
authors
will
look
at
the
XML
anymore.
It's
really
you
guys
that
need
to
look
at
that.
F
Would
it
help
if
we
had
something
like
if
we
asked
ID
nits
to
be
updated
to
highlight
like
where
those
characters
appear.
B
B
Mailing
list
I
think
there
were
at
least
two
out.
There
are
two
issues
right
there
were.
The
first
issue
is
what
to
do
with
the
instant
draft,
and
the
second
issue
was
what
to
do
going
forward
and
without
addressing
the
former.
Let's
address
the
louder
for
the
moment,
which
is
that's
a
topic
for
the
rswg
to
take
up
sorry
I
was
gonna
say
without
addressing
the
former.
What
to
do
about
the
instant
draft.
I
think
that
one's
settled
already
at
this
point,
you've.
B
Sorry,
I've
never
been
accused
of
being
too
soft
spoken
before
what
I
was
going
to
say
is
I.
Think
the
instant
issue
has
already
been
addressed
in
terms
of
the
RFC.
The
louder
issue,
then
I
think
was
a
matter
I
think
John
Levine
had
suggested
that
there
needs
to
be
a
lot
more
guidance
on
the
use
of
Unicode
in
drafts
and
that's
an
issue
for
the
rswg
to
pick
up
and
I.
Think
it'd
be
a
good
idea.
If
somebody
wrote
a
draft
on
that
for
the
rswg.
H
I
just
want
to
reinforce
that
the
tooling
had
been
in
the
way
it
basically
deferred
the
problem
by
not
letting
things
into
the
draft
archive
and
the
intent
of
the
Repository,
and
that
has
not
changed
so
for
weeks.
At
this
point,
people
could
be
introducing
into
internet
grass
not
asking
utf-8
and
arbitrary
parts
of
the
pros,
so
these
are
going
to
eventually
bubble
into
publication
request
and
one
stream
or
another.
G
H
C
H
A
month
ago,
so
there
was
a
long
discussion
when
it
was
a
realization
that
what
the
rsc's
that
defined,
what
we
were
supposed
to
be
said
in
public
RC,
did
along
these
places,
where
it
was.
There
was
a
significant
overreach
on
what
XML
to
Roc
Limited,
primarily
because
of
a
request
that
Heather
put
in
at
the
time
to
control
whether
or
not
we
had
non-esque
utf-8
in
general,
prose
bit.
7991
and
family
did
not
have
that
restriction
and
in
fact
it
explicitly
called
out
it
was.
E
So
I
think
a
little
bit
of
a
process
problem
here,
which
is
we
have
a
situation
where
we
have
an
RFC
which
specifies
what
what
the
tools
are
supposed
to
do
and
then
we've
had
a
bunch
of
freelancing
where
people
went
right
and
made
ad
hoc
changes
so
that
so
the
tools
do
not
confirm
with
that
document,
and
just
tomorrow
we'll
be
discussing
how
to
document
those
that
have
changes.
E
C
J
B
B
Here
Eric
is
that
there
was
a
draft
stalled
on
this
point,
and
so
the
the
question
came
to
us
by
way
of
the
RPC
saying:
here's
the
drought,
the
RFC
says
this,
but
XML
to
RFC
is
doing
that.
What
do
we
do
right.
E
I
understand
but
like
that
is
a
situation
every
day,
because
the
because
the
Twitter
is
not
confirmed
to
someone
9a1
and
so
the
two
or
four
things
that
the
performers
have
known.
Anyone,
and
so
we've
made
a
decision
to
allow
people
to
publish
over
the
circumstances,
but
it
can't
be
the
case.
The
tourists
continue
to
evolve
without
without
this
revision
of
the
rswg.
That's
the
point:
that's
the.
B
A
A
H
A
Let's,
let's
please
take
this
offline,
because
I
think
this
is
actually
the
wrong
place
to
have
this
detailed.
I
I
A
Sure
no
no,
this
is
the
discussion
I
want
to
have,
but
I
don't
want.
I
want
to
have
the
discussion
about
taking
it
to
the
rswg
and
if
that's
the
right
process
here,
another
discussion
that
we
will
have
in.
A
C
Think
so
we
put
a
pin
in
this
for
one
second,
because
I
want
to
go
back
to
Sunday
real
quick,
because
she
asked
the
stream
the
proving
bodies
to
review
the
use
of
you
in
cases
where
the
Unicode
is
important
to
the
operation
of
a
protocol
and
I
want
to
make
sure
that
that
you
heard
that
I,
don't
think
that
review
realistically
will
happen
because
we
don't
look
at
the
XML
right,
and
so
we
can
try
and
we
can
task,
maybe
the
rswg,
with
talking
about
the
the
non-use
use
of
of
Unicode,
but
for
the
U
part
right.
C
F
To
that,
to
that
I
hope
is
to
raise
it
for
your
awareness
and
I
hope
that
the
street
managers
and
those
reviewers
will
keep
it
in
mind
when
they're
looking
at
the
documents,
but
I
do
view
the
RPC
as
the
backstop.
So
if
things
go
by
unnoticed,
we
will
be
asking
questions.
So
that's
something
you
should
also
be
aware
of
right,
we'll
be
asking
for
advice.
If
something
seems
more
than
an
example.
F
A
C
A
The
question
I
mean
like
taking
this
current
example.
It
was
part
of
a
heading
right.
A
A
H
F
Yeah
also
just
Lars,
you
were
talking
about
math
I'm,
guessing
that
a
lot
of
the
math
is
an
artwork
or
source
code
and
the
you
would.
C
C
A
F
I
Does
sound
as
if
the
the
focus
here
should
be
on
the
readability
of
the
document
and
the
interpretability
of
the
document,
not
a
specific
set
of
rules
about
what
is
displayed
when
and
what
is
and
and
those
things,
and
that
that
then
comes
back
to
the
authors
and
comes
back
to
the
ads
and
others
and
ISE
and
others
to
check
that
readability
in
the
same
way
that
it
can
be
affected
by,
and
you
know
ordinary
Latin
characters.
Ordinary
Latin
words
can
have
the
same
issues
so
I.
Think.
I
A
I
Sorry
I
thought
we
were
talking
about
how
authors
are
going
to
work
in
relation
with
the
RPC.
You
know
in
the
80s
and
others
are
going
to
be
able
to
track
documents
that
have
Unicode
in
it.
But
I
don't
see
the
relationship
between
that
and
how
that
means.
We
work
with
rswg.
C
Two
separate
issues
right
one
is
the
very
specific
issue
of
giving
authors
guidance
of
when
they
should
use
the
you
tag
which
expands
to
this.
You
know
Unicode
and
then
parentheses.
What
the
long
name
of
that
code
point
is,
and,
and-
and
the
text
currently
says
you
know
when
it's
important
for
the
operation
for
protocol-
you
should
use
the
U
yes
and,
and
that
is
asking
you
know,
can
the
stream
approving
bodies
review
that
you
is
being
used?
Consistency
like
that
and
I
said
it's
going
to
be
difficult
right.
C
J
So
I'm
really
going
to
try
to
do
this
as
questions
not
comments,
is
there
an
expectation
that
the
rules
are
going
to
be
different
between
the
streams.
A
J
Right
and
then
okay,
this
will
be
a
comment,
not
a
question,
but
the
RFC
doesn't
say
anything
about
this.
This
is
all
in
the,
as
is
draft,
which
still
has
not
been
finalized,
and
so
my
question
is:
are
you
okay,
with
doing
something
in
whichever
RFC
to
be
is
using
a
rule
that
may
end
up
getting
taken
out
of
the,
as
is
that
is
it's
as
is
as
of
today,
but
it
hasn't
actually
been
instantiated
and,
as
we've
seen,
there's
a
lot
of
question
of
whether
we
want
to
do
this
or
not
or
whatever
so.
J
The
alternative
is
to
not
use
you,
that
is,
you
might
disappear,
but
there
hasn't
been
an
agreement
in
the
community
that
you
is
a
good
idea.
You
is
part
of
as
could
be
implemented
so,
and
so
so
that's
that's.
My
question
is,
is,
are
you
okay
with
using
you,
even
though
it
might
not
actually
be
implemented
anywhere
else.
J
C
Two
answers:
one
I
think
we
were
operating
sort
of
under
the
general
principle
and
we
should
probably
spell
it
out
that
you
know
we
want
to
try
to
minimize
differences
between
streams,
because
it
would
be
very
confusing
if
we
did
the
opposite
and
and
so
I
think
that's
the
general
principle
right
and
so
and
I
don't
see
this
particular
topic
well.
I
can't
see
the
reason
why
this
would
differ
between
the
streams
right
and
then
the
second
thing,
yeah
I,
think
we're.
C
You
know
if
the
Community
consensus
around
what
the
tags
are
and
how
to
use
changes.
We
will
follow
along
right,
but
at
the
moment
we're
sort
of
trying
to
follow
whatever
we
have.
J
And
the
reason
I
was
asking
about
the
streams,
is
the
current
wording
and
the,
as
is
document
says,
in
order
to
serve
characters
in
context
that
don't
explicitly
allow
Unicode,
and
that
could
be
different
between
streams.
Some
streams,
for
example,
could
say:
that's
going
to
be
too
confusing,
just
let
it
everywhere
and
other
streams
would
say
we
want
to
call
it
out
so
I'm
glad
to
hear
that
that
may
not
happen.
G
I
I
would
expect
the
streams
to
try
to
to
stay
aligned.
I
Have
a
different
question:
okay,
and
just
to
an
aside
as
far
as
I,
know
and
I
think
as
possibly
as
far
as
you
and
John
know,
this
is
the
only
example
of
where
the
anaz
is
contradicted
or
contradicts
an
RFC.
A
A
Sorry
we
have
to
get
back
to
the
pro
so
like
I'm
checking
where
we
are
so
we,
the
the
we
gave
advice
to
the
RPC.
The
tooling,
was
updated
in
line
with
the
existing
RFC
was
the
tooling
change
announced
to
the
artist
WG
as
well.
Oh.
A
I
A
To
understand
where
we
are
yes,
so
that's
also
what
I
wanted
to
say.
I,
don't
think
it's
good
to
have
these
tooling
announcements
without
any
context,
so
we
should
actually
raise
an
issue,
and
actually
my
understanding
from
the
process
would
be.
It
would
be
the
RPC
rating
this
issue
with
like
we
would
advise
the
RPC
to
raise
the
issue
with
CRST.
B
I
can
check
the
document
if
you
want,
but
I
think
just
when
we
make
decisions
for
transparency
sake
and
just
so
that
no,
you
know
principally
surprised
we
should
inform
the
rswg
of
our
of
our
decision
process.
But
that's
Elliott's
opinion.
I
can
go,
look
at
the
draft
and
see
what
it
says
or
the
rfcs.
C
A
No
I
think
what
we
should
describe
is
not
only.
We
should
not
only
say
that
there
was
a
tooling
update
based
on
a
decision
that
the
ourselves
made,
but
we
should
also
say
that
there's
a
policy
question
that
needs
to
be
addressed
and
what
this
policy
question
is
I
think
that
would
be
more
useful.
A
C
The
use
okay
so
basically
related
to
the
RFC
to
be
yes,.
A
B
Excuse
me
I,
just
I
caught
the
text
actually
in
9280.
all
right.
Here's
what
it
says
if
there's
a
disagree,
it's
couch
in
the
term
disagreement,
but
it
says
in
this
case
the
r
the
rsab
is
responsible
for
a
resolving
the
disagreement
in
a
timely
manner,
if
necessary,
so
that
the
relevant
stream
documents
can
be
published
before
a
new
policy
is
defined
and
B,
bringing
the
issue
to
the
rswg
so
that
a
new
policy
can
be
defined.
That's
in
section
4.4.
A
C
I
think
we
could
have
been
more,
we
could
even
faster
with
informing
the
rswg
I.
Think.
That's
yes,.
A
A
E
E
I
I
think
there's
something
important
about.
This
is
because
the
RSV
is
extremely
low,
operating
parameters
which
are
designed
to
do
exactly
two
things:
to
approve
the
output
of
the
rswg
and
to
in
cases
like
this,
to
make
changes
in
a
little
rswg
they're,
not
an
independent
body
which
makes
policy
about
this.
E
A
Yes,
we
have
I
think
we
just
have
a
different
interpretation
of
timely,
because
this
is
like
a
matter
of
a
few
weeks
right
and
we
are.
We
are
we're
organizing
this
meeting.
So
we
have
this
meeting
to
actually
document
in
our
minutes
that
we
discussed
this
issue,
and
this
is
the
right
time
to
reach
out
to
the
rswg
and
like
I.
Don't
really
understand
your
point
because,
like
informing,
you
like
three
weeks
earlier,
wouldn't
really
change
anything
right,
because
the
hours
WG
is
also
not
operating
on
a
daily
basis.
C
It's
not
about
it's
not
only
about
whether
it
would
have
changed
something,
it's
also
about
the.
What
what
impression
does
it
set
or
what
does
it
give
right,
because
I.
C
Of
the
concerns
that
led
to
the
creation
of
the
structure
was
that
the
r
stock
was
very
in
transparent
and
did
stuff,
and
the
community
wasn't
involved
and
the
community
decided
on
a
process
where,
as
Echo
said
right,
the
rswg
is
the
the
debating
body
and
we
are
the
approval
body
and
we
have
a
little
bit
of
mandate
to
do
things,
because
otherwise
the
queue
stops
and-
and
this
was
a
case
where
the
queue
would
have
stopped
for
this
document.
And
so
we
did
a
decision,
but
that
the
I
think
implied
immediate.
G
It
seems
like
there's
just
some
disagreement
or
confusion
about
what
timely
means
here
and
I
think
what
we
probably
need
to
do
at
this
point
is
write
down
what
our
expectations
are
and
get
agreements
on
them.
So
we
understand
what
timely
actually
means
in
this
case
and
whether
that's
within
a
day
whether
that's
within
a
month
or
a
week.
G
H
Think
just
we
can
take
the
request
that
you
know.
The
reaction
that
we're
seeing
here
is
is
that
over
communication
is
likely
to
hurt
less
than
under
communication,
so.
A
A
Business
I
mean
like
this
was
blocking
something
in
a
queue
right,
so
we
made
a
decision,
but
anything
that
follows
is
a
much
longer
timeline,
but
I
don't
see
what
the
urgency
is
and
I
would
much
rather
have
these
things
put
up
on
a
meeting
agenda
and
put
them
in
the
meeting
minutes
and
have
them
documented
right
correctly
and
then
Reach
Out,
rather
than
doing
something
on
on
a
haste
without
need.
I
The
difficulty
is,
though,
that
the
tools
implementation
took
place
some
weeks
ago,
so
we
have
the
decision,
made
tools,
implementation
and
then
a
significant
time
before
the
rswg
is
told
that
that
that's
the
issue.
If
we've
made
the
decision
and
nothing
had
happened
with
it,
I
can
understand.
Then
you.
I
A
But
you're
saying,
if,
if
we
should
have
informed
them
before
the
tools
change
happened,
this
is
gives
them
a
chance
to
interview
them.
C
C
C
And
not
tell
the
community
for
a
while
right.
It's
it's
a
pattern
that
the
asok
used
to
have
they're
delayed
for
much
longer
and
sometimes
never
told
right.
But
but
it's
the
community
expects
transparency
and
expects
it
in
a
timely
manner
and
in
this
case
I
think
you
know
reasonably,
so
we
didn't
deliver
because
we
took
too
long
to
let
them
know,
even
if
they
wouldn't
have
started
work
until
this
meeting
or
next
meeting
it's
about.
When
did
the
information
get
passed
out
of
the
RSA.
G
I
Can
I
just
suggest
perhaps
that
we
just
have
a
little
bit
of
formalism
around
what
a
published
decision
is
because
then,
and
then
that
formalism,
that
publish
thing
is
what
goes
to
the
tall
scene.
What
goes
to
rswg?
What
goes
to
the
RPC
you
know,
and
then
everybody
then
gets
it
at
the
same
time
and
then
implements
at
the
same
time.
So
it's
transparency
that
way,
because
what
it
could
feel
like
to
some
people
is
that
we
made
a
published
decision.
I
A
G
G
G
C
B
Let's,
let's
pause
for
a
moment
and
my
suggestion
is:
we
clearly
have
a
decision
process
issue
on
our
side,
let's
think
about
it
in
the
meantime,
as
if
we
have
other
decisions
to
make,
let's
make
sure,
at
least
in
an
ad
hoc
fashion,
that
they're
spread
widely
is
as
quickly
as
possible
and
then
let's
sort
a
proposal
for
how
we
do
our
decision
process.
That
way,
maybe
we
can
move
forward
now,
I,
like
Jay's
proposal,.
G
I
My
suggestion
was
in
an
attempt
to
take
away
worrying
about
what
timely
is
by
saying
that
when
we
think
we've
made
a
decision,
we
write
it
up
as
anything
and
that
it's
a
it's
a
document,
whatever
some
kind
of
structure,
and
that
is
what
is
sent
to
the
RPC
to
you
know
to
the
tools
team
if
required,
anti-rswg.
So
there
is
just
a
thing
and
nothing
happens
until
we've
agreed
that
document
and
once
we've
read
it,
it's
published,
everyone
can
have
it
that.
A
C
I
mean
yes
right,
because
we
need
a
document
that
we
came
to
an
agreement
in
some
form
and
that
but
I
have
a
record
and
at
the
moment
at
the
moment,
we're
doing
this
by
email
and
that's
fine
too.
But
but
that's
exactly
what
like
I,
think
how
we
need
to
record
that
we
made
decisions
on
the
r
set.
A
C
A
Anyway,
if.
C
Exactly
but
if
we
so
the
only,
we
can
only
say
that
the
meeting
is
the
time
when
we
do
these
actions.
If
we
actually
wait
until
the
meeting,
but
because
we
are
only
supposed
to
take
actions
when
there's
an
immediate
need,
I
don't
see
how
we
can
delay
things
until
the
next
meeting
and
still
say.
We
need
to
take
immediate
action
and
settlement
for
two
months
because
sort
of.
C
I
think
everybody
who's
not
on
the
rsap
quickly
is
reconsidering
whether
you
want
to
attend
future
meetings,
because
these.
A
Great
first
decision
we
take
when
we
don't
know
the
process;
okay,
that
was
not
unexpected.
Okay,
let's
move
on.
F
Okay,
so
the
rest
is
just
check-ins.
It's
wanting
to
see
if
any
of
the
street
managers
had
any
concerns
or
comments,
feedback
about
how
the
inclusive
language
process
is
working
or
how
the
auth48
archive
is
working.
G
So,
as
far
as
I
can
tell,
the
of
48
archive
is
working
fine
and
it's
completely
invisible
to
everyone.
Apart
from
people
who
go
search
it
out,
inclusive
language
seems
to
be
working
fine.
Every
time
traditional
gets
flagged
up.
Someone
asks
the
question
about
why
that
is.
We
may
need
to
provide
some
more
guidance
for
that,
but
other
than
that
yeah
it
seems
to
be
working.
Fine
from
my
point
of
view,.
F
G
Why
I
think
in
this
case
you
know
some
of
the
other
cases.
People
understand
intuitively,
why
this
is
being
flagged
up,
but
that's
one
that
people
don't
seem
to
understand
intuitively.
So
we
may
need
to
point
to
you
know
explicit
chapter
of
verse.
You
know
subsection
4.2
of
the
next
document,
because
people
don't
seem
to
find
it.
C
Yeah,
the
Middle
Point
again,
so
we
talked
about
this
with
the
isg
on
on
Sunday,
so
we
should
maybe
take
it
out
of
the
isg
Sunday
since
we're
going
to
talk
about
it
here,
which
is
the
more
appropriate
Forum
similar
to
call
an
all-48
works.
Great
air
directors
really
rely
on
it
already
we
can
produce.
It
makes
it
easy
to
send
a
link
to
somebody
to
point
them
at
a
specific
comment
that
was
made
during
affiliate.
C
If
it
wasn't
possible
before
inclusive
language
seems
to
work,
fine,
the
the
only
thing
we
talked
about
is
on
Sunday
I'm,
just
mentioning
it
here.
For
those
of
you
who
weren't
there
I
I
think
the
language
that
you're
using
is
fine
in
the
sense
that
you
are
it's
very
clear
to
me
at
least
that
you're
trying
to
suggest
to
authors
that
they
review
the
use
of
those
terms,
and
but
some
authors
seem
to
misunderstand
it.
C
As
you
know,
the
RFC
that
told
me
to
change
this
words
and
how
dare
they
or
or
I,
don't
understand,
I,
don't
know
if
these
these
things
can
be
further
clarified,
I
think
it's
a
very
small
fraction
of
authors
that
is
confused
in
this
way,
but
it
is
a
thing
right
and-
and
thank
you
so
if
there's,
if
there's
better
words
that
you
could
put
in
in
the
the
first
paragraph
of
this
thing,
but.
A
Let
me
make
a
suggestion:
I
think
one
point
is
like
that
people,
don't
don't
see
it
as
like
a
request
to
review,
but
it
requires
to
change.
But
you
know
that's
I.
A
People
just
don't
understand
it,
but
the
other
point
is
that
not
all
of
these
works
and
that's
written
in
this
document,
but
nobody
clicks
on
that
and
reads
in
this
document
right.
So
not
all
of
these
words
are
like
necessarily
extremely
like
exclusive
or
whatever,
but
some
of
them
are
just
like.
F
A
I
totally
understood
that
this
document
is
like
very
broad
right
like
if
you
look
at
some,
maybe
other
documents,
they
specifically
focus
on
The
Words,
which
are
somehow
but.
A
No,
no
I'm
not
discussing
this
document,
I'm
just
saying
that,
there's
like
a
set
of
words
where
people
understand
they
are
kind
of
exclusive
because
they
have
like
a
very
specific
wording
in
there.
But
then
this
document
is
much
broader
than
that
and
has
like
a
lot
of
words
which
are
just
like
unclear
because
of
cultural
references,
and
that's
something
that
I
don't
think
is
clear
to
people
so
spelling
that
out
why
this
document
is
so
broad
like
adding
a
sentence
to
it
might
help.
F
A
C
A
C
But
I
mean
it's
so
I've
liked
these
as
part
of
my
ad
reviews,
all
right
or
I,
try
to
and
and
I
tried
to
say
the
same
thing.
You
know
it's
an
ask
for
review
and
if
somebody
says
I
reviewed
it
and
I
think
this
usage
is
fine.
C
I'm
very
happy
to
accept
that
right,
but
but
I
think
it's
I
think
it's
very
clear
what
you
have
I
don't
know
if
it
can
be
improved,
if
you
can
think
of
a
way
that
would
be
great,
but
I
think
we
are
already
at
the
point
where
there's
a
very
small
fraction
of
authors,
that
misunderstand
what
they're
being
asked
to
do
right
and
so.
F
Okay,
so,
like
I,
said
we'll
review
and
see
if,
if
we
can
do,
maybe.
C
Ask
the
individual,
which
words
would
have
been
clearer
and
we'll
see
if
they
will
be
generally
more
clear
or
just
individually,
more
clear
and
okay,
the
new
another
thing
for
the
IB
there.
That's
that's
it
also.
G
I,
don't
think
trying
trying
to
get
to
the
stage
where
no
one
is
confused
about.
This
is
a
realistic
goal.
There's
always
going
to
be
a
few.
A
F
Okay,
the
last
one
is
actually
something
we
could
probably
just
talk
to
Maria
about,
and
really
it
was
just
there's
some
guidance
that
the
IAB
provided
to
us
a
while
ago
that
outlined
some
details
about
how
the
different
documents
should
be
formatted
and
some
of
the
documents.
Recently
there
were
some
updates
that
were
pretty
time
consuming,
and
so
we
were
just
wondering
if
there's
a
way
that
we
can
update
yeah.
A
We
definitely
should
I
just
wasn't
sure.
So
you
said
the
the
IV
was
writing
this
document
and
providing
it
to
you.
It's
most,
not
wasn't
you
writing
the
document
and
then
agreeing
with
CIP.
So
your
expectation
is
that
the
iub
is
updating
the
document.
Or
do
you
want
to
propose
updates
as
a
document
of
the
IEP.
F
F
B
B
But
it
opened
a
a
bit
of
a
question
which
is,
if
we
have,
if
there
are
any
IAB
documents
that
touch
on
rfcs,
that
weren't
updated
there
may
be
a
need
to
one
of
the
things
we
didn't
cover
in
9280
was
how
to
handle
their
autumn,
and
there
are
audits.
So
I
don't
have
a
specific
suggestion,
I'm,
not
even
sure,
if
it's
a
real
problem,
yet
because
this
was
such
a
peculiar
erotic
itself,
but
that
this.
B
Well,
so
in
in
be
that
as
May
one
thing
we
should
just
keep
keep
an
eye
out
for
is
whether
or
not
the
the
rswg
should
has
anything
to
do
there
in
terms
of
providing
a
policy
for
updating
Errata
of
these
sorts
of
things.
I'm
not
sure
there
is
yet,
but
it
was
a
things
happened.
Pretty
quickly.
Was
it
last
week
two
weeks
ago
and
I
just
want
to
make
sure
we
don't
you
know
we
have.
We
have
in
fact
informed
people
what
we
did
and
who
did
what
so.
I
Earlier
I,
don't
think
it
is
formally
obsolete,
I
think
it's
implicitly
obsolete
by
the
new
model,
possibly
but
I.
Don't
think
it's
formally
obsoleted,
because
the
new
model
didn't
follow
the
path
backwards
of
boilerplates
to
see
what
documents
are
updated.
By
changes
that
it
made.
B
So
this
had
to
do
with
RFC
5741,
and
there
was
some
text
in
there
that
said
about
about
how
how
and
when
how
boilerplate
is
meant
to
be
used,
and
a
correction
was
proposed.
Now,
if
I
go
to
so.
A
That
that
specific
area
was
deleted
because
it
was
a
duplicate
from
an
existing
editor
that
was
verified
at
some
point
like
that,
this
whole
is
hold
for
a
document
update
I
think
so
this
error
is
not
our
problem
at
the
moment,
but
it's
a
more
general
question
about
error
tests
that
are
raised
against
iob
documents
that
Define
the
ROC
process
because
and
like
I
think
it's
it's
an
even
broader
question
about
what
like
we.
A
B
We
actually
looked
at
that
that
came
up
in
the
working
group
previously
yeah
right,
and
we
chose
to
defer
that
question
specifically.
So
this
is
something
the
rswg
might
want
to
put
a
little
energy
into
at
some
point
just
to
see
which
documents
the
the
editorial
need
to
be
in
the
editorial
series
and
under
editorial
stream
control
going
forward.
I
don't
have
any
specific
suggestions
as
to
which
ones
at
this
point
it's
just
there
may
be
a
little
work
hiding
there
a.
C
Different
suggestion-
and
that's
maybe
a
bit
more
pragmatic
in
the
sense
that
so
there's
a
bunch
of
documents
in
that
are
historically
in
the
IAB,
and
they
talked
about
previous
RFC
editor
models
that
are
not
in
effect
anymore
and,
frankly,
I
don't
care
who
proves
the
rather
for
those
or
not
approve
them,
because
they
don't
change
anything
right,
because
if
I
have
the
other
model
2,
you
know,
if
you
prove
around
us,
all
you
want
is
not
going
to
change
how
RCS
are
produced.
C
Stream
that
wasn't
done
yet
right
so
for
documents
on
the
IB
stream
that
still
impact
how
rfcs
get
produced
and
how
the
IFC
process
works.
C
Right
I
would
expect
the
RPC
where
they
get
raised,
to
bring
them
to
the
r
sub,
because
I
thought,
as
far
as
I,
remember
and
maybe
I'm
wrong
here.
But
it's
it's
not
the
RSL
ugu.
It's
the
stream,
improving
body
for
the
electronic
screen
with
the
r
step
right,
because
the
stream
improving
body
decides
only
around
us.
C
C
E
Yeah
I
think
I
would
suggest
that
the
ID
simply
just
delegate
it
and
totally
effectively,
and
you
know
you
could
choose
to
undelegate
at
any
time.
But
you
just
say
once
last
year
are
sad
and
then
our
samples
and
we'll
sign
off
on
it
and
they
don't
do
any
processes.
F
C
Right,
we're
gonna,
we're
gonna,
build
a
list
of
rfcs
incrementally,
as
Iran
has
come
in,
and
we
realize
this
is
one
where
you
know
it's
on
the
IRB
stream.
It
still
has
an
effect,
so
it
should
be.
The
i7
will
be
added
to
the
list
and
we
need
to
figure
out
where
we
maintain
this
list
I'm.
Just
basically
trying
to
not
have
us
do
the
work
of
comp
trying
to
compile
this
list
now.
F
F
A
Okay,
that
sounds
like
a
good
approach
to
me,
as
I
said:
I
will
bring
it
back
to
the
IEP
and
try
to
minute
it
in
the
ibmits.
Is
that
something
we
need
to
inform
the
rswg
about.
G
A
E
C
Having
to
like
find
them
on
the
website
or
wherever
they
go
and-
and
you
know
whether
we
send
an
extra
email
or
we
forward
the
the
minutes
to
them-
I
don't
know
if
we
don't
forward
the
minutes
already.
You
probably
should
anyway.
F
A
No
sir
I
have
no
question
and
there's
this
broader
policy
question
about
also
kind
of
does
the
IB
have
to
agree
if
those
documents
gets
obsoleted
or
updated
or
whatever
I
think.
That
is
this
question
that
should
be
raised
with
the
rswg
and
I'm,
not
sure.
If
there's
an
issue
on
the
RS
WG
already
so.
C
I
think
it's
a
related
question
and
I
think
sort
of
morally
iib
has
sort
of
given
away
the
control
of
the
of
the
RFC,
editor
right
and
so
I
think
similar
to
how
they
would
you
know
they
should
delegate
the
a
rather
approval
to
the
rsf
they
for
those
other
documents
on
their
IEP
stream.
C
They
should
also
delegate
decision
on
updates
or
obsoletations
through
the
RS
app,
because
so
the
the
principle,
if
you
look
at
it
in
other
ways
like
under
the
current
model,
these
documents
would
have
been
published
on
the
editorial
stream
right
because
that's
like
where
they
would
go
going
forward
and
so
we're
trying
to
sort
of
like
grandfather
them
in
sorry.
For
using
that
term,
somehow
and-
and
so
the
IB
basically
should
I.
A
Mean
yes,
they
should
I'm
just
asking
about
the
process
because
I
mean
at
the
end.
That's
an
even
broader
question
like
how
do
we
generally
handle
the
process
is
like
one
stream
updates
or
obsolete
document
from
another
stream,
because
that's
also
it's
not
the
only
case
here.
H
E
Might
be
able
to
but
I
guess,
I
guess
one
thing
I'd
point
out
that
a
lot
of
no
actual
Force.
So
this
is
not
a
so
you're,
not
changing
the
documents
at
all
when
you
open
a
router
because
they
have
an
actual
force.
E
And
of
course
you
know
we
could
retractively
change
the
stream,
but
since
there
aren't
very
many
of
them
and-
and
it
seems
like
the
IV
IB-
has
free
to
approve
or
not
approve
a
lot
as
they
please
in
any
fashion
they
place
and
the
process
they
use
can
be
pretty
well
to
ask
the
RCB,
What,
It
Takes
and
then
take
the
rcb's
answer
and
the
reason
to
change
right
document
would
be
at
the
RSA
or
IB
wish
to
like
reserve
the
restore
like
itself
from
the
right
to
like
take
that
back.
E
But
as
long
as
I
I
think,
we
should
like
give
up
the
right
to
take
around
those
documents.
But
I
don't
see
the
reason
why
you
need
to
do
that
and
so
I
think
it's
easiest
which
is
just
to
firmative.
The
IV
approves
them,
but
informally
asked
rsat.
E
E
C
I
was
going
to
say
so
for
for
the
updates
and
obsoletions
right,
I
think
what
we
can
actually
do.
Is
we
because
you
can't
obsolete
something
from
another
stream,
but
the
IAB
can
basically
at
the
point
where
the
other
rswg
publishes
a
new,
a
new
document
on
their
Twitter
stream.
That's
intended
to
obsolete
something
you
can
just
Mark
that
thing
as
historic,
but
the
IB
takes
an
action
to
mark
their
document
as
historic
and
there's
a
new
document
now
and
there's
no
obsolete
relationship
between
the
streams
that
way
yeah.
A
Known
so,
but
it's
also
not
true
that,
like
a
document
from
one
stream
cannot
obsolete
the
document
from
another
student,
no,
this
happened
like
for
dtn,
at
least
okay,
because
we
don't
have
any
rules
on
that.
So
that's
what
I'm,
trying
to
say,
I
think
we
should
have
actually
written
a
policy
down
and
that
should.
C
G
B
C
Number
one-
and
it
relates
to
the
Legacy
stream,
which
also
sees
around
us
and
and
where
we
also
have
the
case
where
sometimes
IDF
documents
want
to
update
and
the
Legacy
documents,
and
we
have
at
least
some
community
members
that
are
vehemently
opposed
of
the
iitf
touching
the
Legacy
stream
in
any
way
because
it
predates
Us
and
how
dare
we
right
so
that
that's
a
discussion
that
ourselves
really
could
have
in
in
that
space?
C
I
H
H
H
A
A
A
C
A
That's
the
plan,
and
even
if
we
don't
have
anything
in
Yokohama,
we
might
not
have
one
okay,
but
the
intention
is
to
have
it
in
your
karma.
That
would
be
that
would
at
least
be
my
impression.