►
From YouTube: IETF115-RSWG-20221108-1300
Description
RSWG meeting session at IETF115
2022/11/08 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
A
D
B
C
C
Well,
we
can
start
going
through
intro
slides
all
right.
Why
don't
we
at
least
start
getting
through
the
intro,
slides
and
fun
stuff
like
that?
Welcome
to
rswg
it
is
only
Tuesday,
so
we
shall
note
the
note.
Well,
although
everybody
in
this
room,
better
bloody,
well,
know
the
note
well
at
this
point:
We
are
following
ietf
procedures.
If
you've
got
questions
about
them,
perhaps
you'd
like
to
step
out
before
you
participate.
C
So
we've
got
a
discussion
of
the
SVG
stuff
up
front.
What
we're
going
to
do
about
the
SVG
profile,
then
a
discussion
of
the
79
91
bis,
as
is
draft
and
whether
that
needs
to
be
adopted,
Etc
and
so
forth,
and
then
a
79.91
this.
What
we
want
it
to
be
draft
and
then
after
that
discussion
is
done
all
other
business,
any
agenda
bashing
anything
else
we
need
on
here
he
looks
to
the
room.
He
looks
to
the
chat
Lars.
A
C
B
B
H
H
H
Standing
back
here
right
so
Brian
submitted
this
draft.
It's
a
collection
of
I
guess,
you
might
say,
problems
gripes
and
aspirations
as
to
what
we
can
do
with
svgs.
This
applies
to
now.
He
says
SVG,
RFC,
1.2,
I,
don't
know
what
1.2
is
so
I'm,
not
sure
what
that
means,
but
presumably
this
means
79
7996.
H
H
I
think
there
are
a
number
of
reasons
for
the
restrictions
in
7996,
and
that
was
maybe
one
of
them
next
slide.
Please
so
I
think
probably
the
biggest
problem
that
we
have
here
is
this
first
point:
there
are
some
tools
that
can
produce
spgs
that
comply
with
the
profile
that
we've
invented,
but
not
very
many
of
them.
H
H
Yeah
this
surprised
me,
but
it
turns
out
that
some
tools
put
Javascript
in
svgs
because
and
likely
for
good
reasons.
Not
all
viewer
tools
were
like
we'll
process
that
JavaScript,
but
there's
a
number
of
cases
where
they
put
it
in
just
in
case,
because
we've
got
certain
browsers
if
we
need
to
work
with
or
something
I,
don't
know,
there's
a
whole
bunch
of
transform,
metrics
and-
and
things
like
that,
I
think.
H
The
point
here
about
transforming
text
into
separate
letters
is
what
I
would
call
a
bug
on
the
part
of
the
tool
that
generates
the
SVG.
I
took
a
brief.
Look
at
one
one
example,
which
was
I,
think
the
goat
tool
does
that
that's
a
to
my
mind,
a
bug
I
have
an
implementation
that
does
basically
the
same
thing
that
puts
all
of
those
characters
into
the
same
string
and
it
works
perfectly
fine
modulo,
some
font
metric
issues
and
the
other
one.
H
H
So
Brian
also
knows
that
the
ASCII
art
Alternatives,
although
I,
believe
that's
largely
been
addressed
from
the
perspective
of
the
format
itself.
There's
potentially
a
need
for
some
of
the
tooling
around
that
to
ensure
that
something
sensible
gets
produced
on
the
ASCII
side
of
things
when
we
have
a
diagram
produced
as
SVG
last
slug,
please.
H
So
a
suggestion
here
is
to
take
a
look
at
7996
and
change
it.
Concentrating
on
the
things
that
are
forbidden
is
probably
a
sensible
approach,
in
my
opinion
as
well.
The
restricted
grammar
has
turned
out
being
to
be
rather
restrictive,
and
it's
probably
not
the
case
that
the
that
the
tooling
we
have
is
incapable
of
dealing
with
a
lot
of
these
things.
It's
just
that
we've
profiled
them
away
and
that
part
of
the
reason
I
believe
that
we
were
profiling
them
away.
H
The
accessibility
side
of
things
becomes
particularly
interesting
and
we've
had
a
number
of
discussions
on
the
mailing
list
about
this
particular
aspect
of
it.
There
are
probably
some
accessibility
guidelines
we
can
lean
on
for
for
this,
and
then
we
also
have
the
question
of
how
much
of
that
belongs
in
style
guide,
as
opposed
to
sort
of
policy
format,
related
documents
and
we'll
probably
have
to
work
through
that
in
practice,
as
well
as
in
terms
of
understanding
what
the
the
format
documents
say.
In
the
end,
we
have
a
queue.
This
is
the
end.
I
Go
down
the
path
that
you're
suggesting
here
build
a
set
of
recommendations
about
what
can
appear
in
rfcs
yeah,
speak
in
terms
of
policy,
not
in
in
terms
of
implementation,
but
keep
in
mind
that
we
will
have
to
build
tools
for
the
authors
and
tools
for
the
RPC
and
in
particular
watch
out
for
making
it
hard
to
build
something
for
the
RPC.
That
would
let
them
make
something
that
meets
the
spirit
of
the
recommendations
out
of
somebody
that
handed
them
complete,
smash,
yeah
right.
H
Yeah
so
we've
seen
a
number
of
cases
where
the
complete
Mash
has
been
been
dropped
on
people
and
I
I
think
that
whatever
we
can
do
to
to
first
of
all,
have
a
style
guide
that
says
these
these
things
and
not
sensible.
Please
don't
submit
these
and
then
at
the
tail
end
turn
it
into
something
that's
practical
for
for
the
tooling
and
the
people,
because
ultimately,
we've
got
to
put
this
through
that
process
to.
I
E
H
Yeah
I
I
think
that
probably
having
having
no
scripting
is
a
pretty
simple
thing
to
do
and
a
pretty
simple
thing
to
remove.
But
when
it
comes
to
some
of
these
other
features,
we
have
to
think
about
the
entire
production
pipeline
that
we
have
and
everything
that
it
touches
along.
The
way.
One
of
the
things
we've
seen
particularly
with
XML
to
RSC
recently,
is
that
Wheezy
print,
which
is
what
we're
currently
using
to
produce
PDFs,
has
a
number
of
restrictions
in
it.
C
H
A
A
One
is
we
might
want
to
impose
some
complexity
limits
on
the
document,
but
the
the
figure
right
and
there's,
depending
on
what
we
want
to
do
right,
different
things
lend
themselves
to
to
baby
being
a
bit
easier
than
like
again
going
down
the
XML
path
and
like
restricting
the
language
in
certain
various
ways.
So,
for
example,
we
could
for
if
we
were
worried
about
complexity
of
figures,
we
could
entirely
leave
it
up
to
the
review
process
to
like
flag
those
archivability.
A
J
Phil
Han
Baker,
so
two
points
here
number
one:
you
asked
for
being
able
to
do
text
and
SVG
the
tool
I'm
using
is
gotify
I
had
to
modify
it
so
it
produced
code
that
fits
the
tiny
SVG
thing.
But
if
you
look
at
all
the
specs
for
the
math
mesh,
all
the
diagrams
in
the
HTML
version
are
being
generated
from
text.
That's
then
converted
to
SVG.
J
B
B
To
avoid
your
creating
exercise
problems
when
you
like
load,
you
know
someone
else's
diagrams
into
your
into
your
web
page
and
and
for
accessibility
for
the
data
right,
so
I
do
think
the
fir.
Some
of
them
are
straightforward.
The
archival,
archival
I'm
actually
quite
concerned
about
for
the
following
reason
that,
like
you
know,
and
then
this
is
going
to
go
back
to
like
a
much
like
a
deeper
conversation
about
cavity.
B
But
the
bottom
line
is
that,
like
the
Concepts,
such
as
it
is
behind
the
XML
data
structures?
Is
that
like
one
could
at
least
theoretically
read
them
and
like
mentally
process?
What
the
XML
data
model
was
and
I'm
sure
the
context
was
and
like
without
the
software's
job
is
to
render
that
into
like
into
like
a
raster
format.
B
That
is
like,
perhaps
more
aspirational
and
true,
but
it
is
like
somewhat
true
that
is
entirely
false.
Refugee
right,
there's
no
way
to
look
at
the
SVG
and
like
if
any
idea
was
going
to
render
at
like
in
any
sensible
way
right.
You
can't
hand,
evaluate
it
and
so
I
think,
if
our
of
our
view
I
think
if
we're
gonna
have,
if
we're
gonna
we're
at
a
high
probability,
that
actually
requires
stepping
back
and
asking
what
the
real
question
for
probability
and
future
future
accessibility
is
for
these
mini
formats.
B
And
if
it
in
fact
is
the
case
that
we
expect
someone
to
be
able
to
read
the
canonical
format
without
the
AF
software.
And
if
that
is
true,
then
essay
does
not
acceptable
like
format
at
all.
And
if
it
is
not
true,
then
like
then
like.
Actually
many
of
these
issues
becomes
like
relevant
because,
like
you
know,
you
can
download
operation,
complicated,
SVG,
processor,
so
I
think
trying
to
like
I.
H
B
H
K
H
I
I
think
that
the
having
some
sort
of
guidelines,
as
in
terms
of
what
is
the
legibility
of
of
the
content
when
rendered
in
a
particular
size
is,
is
one
of
the
ways
you
can
approach
the
complexity
problem.
The
other
is,
is
simply
how
many
SVG
components
in
there.
If
it's
several
megabytes,
then
it's
probably
trying
to
like
there's
there's
a
few
things
you
can
look
at,
but
no
one
of
these
things
is
going
to
tell
you
definitively
that
this
is
bad
because
I,
you
know,
Liz
has
a
draft.
H
That's
got
some
some
math
in
it
and
some
of
those
look
a
little
fiddly,
but
every
single
one
of
those
is
perfectly
fine.
It's
exactly
the
sort
of
thing
that
we
should
be
doing
with
SVG
in
in
documents.
So,
yes,
this
will
be
judgment
and
I
think
it
will
come
down
to
learning
over
time
what
what
people
find
is
acceptable
or
not.
Maybe
some
discussions
with
various
streams
in
terms
of
what
they're
willing
to
accept.
H
F
F
H
F
I
think
it
would
be
unwise
for
us
to
try
to
invent
accessibility
requirements,
but
I
think
there's
a
rich
literature
that
we
can
draw
on,
because
people
yeah,
of
course,
basically
yeah
people
have
been-
have
been
making
versions
of
books
for
blind
people
for
a
century.
I
mean
this
is
this
is
not
an
this
is
sort
of
it's
obscure,
but
it's
not
poorly
understood
and
it
and
and
people
have
a
lot
of
experience.
Sure.
D
C
L
L
I
can
definitely
show
you
some
ASCII
diagrams
that
are
particularly
horrible
and
in
fact
the
SVG
looks
better
in
some
cases,
because
you
can
make
things
a
little
bit
more
readable
in
in
the
SVG
format,
sometimes
even
especially
with
sequence
flow
diagrams
that
have
options
so
I'm
not
sure
what
to
do
about
that.
But
I'll
just
point
out.
J
There
should
never
be
a
requirement,
and
you
know
if
you've
not
got
the
descript.
If
you
have
to
understand
the
diagram
to
understand
the
spec,
then
you're
doing
it
wrong
and
we've
got
other
problems
with
the
spec
and
so
I
think
a
lot
of
our
accessibility
problems
that
we're
putting
into
the
document
format.
If
we
take
that
principle
on
board,
they
just
disappear
because
you
know
if
you
are
colorblind
and
you
can't
understand
the
colors
in
the
diagram.
Well,
the
text
should
be
giving
you
that
information.
H
A
M
N
B
Whoever
it
is
the
next
topic
and
is
what
are
we
to
do
with
the
various
7991
as
his
documents
I,
think,
there's
General
consensus
and
feel
free
to
disagree
with
me
that
we
have
to
have
such
a
document
and
ought
to
document
the
tools
as
they
currently
exist
and
then
not
be
continuously
updated
and
I.
Think
the
question
from
earlier
at
that
point
too,
but
I
think
the
part
of
the
question
was:
do
we
need
to
like
run
it
through
some
complicated
RFC
process?
L
So
I
think
when
Eric
asked
me
to
do
this,
that
maybe
there
was
hope
for
a
sort
of
Point
Counterpoint,
but
it
could
well
be
that
we're
not
going
to
get
there
I
think
there
are
a
couple
of
parameters
we
need
to
look
at
in
terms
of
how
we
answer
this
question.
The
first
is:
how
often
are
we
going
to
update
this
thing?
L
If,
on
the
other
hand,
we're
going
to
allow
for
continuous
update
that,
then
an
RFC
is
not
efficient
for
that
right.
It
takes
too
much
effort
to
continuously
publish
and
the
RFC
editor.
The
RPC
in
the
background,
is
probably
going
thinking
to
themselves.
Yeah,
don't
don't
don't
don't
make
us
have
to
constantly
redo
the
same
document
with
small
changes,
so
I
think
the
velocity
of
change
and
how
often
we
want
to
mark
that
change
are
really
the
parameters.
For
me
so
I
guess
it's
a
matter
for
where
do
we?
What's?
L
H
Yeah,
let's
go,
let's
go
to
the
next
one.
This
is
all
of
the
slide,
all
the
actual
content
of
the
slide,
so
I
think
probably
the
Elliot
may
have
conceded
the
point
already.
This
is
changing
and
will
continue
to
change.
So
it
seems
like
it's
kind
of
bring
up
all
these
other
things,
but
I
don't
think
it's
really
in
our
interest
to
publish
a
document
that
doesn't
really
represent
the
consensus
of
the
the
group
that
this
is
the
right
format
to
be
to
be
using.
H
There
will
be
a
period
of
time
during
which
we
will
not
have
a
document
that
definitively
defines
the
format
of
rscs,
and
that
period
of
time
is
always
going
to
be
finite
because
it
will
exist
in
the
past.
We
can't
fix
that
I
can't
change.
That
I
will
point
out
that
the
document
is
already
in
the
record.
I
believe
that
anyone
who
does
care
about
understanding
the
format
can
go
and
read.
John's
draft
and
it's
close,
but
not
100,
accurate
in
terms
of
the
the
details.
H
H
So
other
people
pointed
out
that
perhaps
it
creates
a
bad
precedent
regarding
the
content
of
the
editorial
stream
I,
don't
particularly
mind
that
it
might
create
friction
against
doing
a
better
job
later.
I,
don't
know,
I
suspect
that
the
right
answer
here
is
is
to
think
about
this,
as
as
an
input
to
a
process
that
we're
about
to
undertake
to
look
at
the
way
that
that
the
format
is
going
to
be
defined
more
formally.
H
C
L
This
is
a
lot
of
work
or
no.
This
isn't
that
much
work,
and
if
we
see
that
there's
a
lot
of
work
to
get
to
where
we
want
to
go,
then
I
would
say.
Probably
you
want
to
publish
that
which
is
so
I
think
it's
almost
premature
to
answer
the
question.
I
think
the
first
exercise
is
to
figure
out.
Where
do
we
want
to
go
and
how
much
work
is
it
to
get
there
and
where
are
we?
If
we
answer
those
two
questions,
then
this
question
becomes
I
think
a
little
bit
easier
to
answer.
I
I
I
think
that
we're
going
to
find
if
we
start
down
the
path
that
Elliot
was
suggesting
of
looking
at
the
inventory
that
I
I
think
would
keep
even
before
we
stepped
out
of
this
room.
It's
my
opinion
that
we
will
say:
wow,
that's
big
and
it's
a
lot
so
I
will
just
throw
up
as
a
a
strong
hand
for
that's
big
and
that's
a
lot.
O
Paul
Hoffman,
so
I
have
an
issue
with
the
word,
publish
as
I,
think
and
I
want
to
check.
You
mean,
publish
as
an
RFC
right.
Okay,
I
think
we
need
to
publish
individual
checkpoints
at
a
stable
long-lived
URL
which
the
RFC
editor
has
for
whatever
we
do.
However,
we
do
this
I
think
that's
just
fine
I
think
we
can
publish
rfcs.
We
don't
have
to.
O
I
already
gave
a
presentation
and
somewhere
else,
I
I,
think
on
this
publish
or
not
publish,
I
think
that
it's
somewhat
of
a
red
herring,
because
this
is
all
ignoring
the
fact
that
if
we
do
something
in
this
working
group
and
say,
okay,
that's
a
checkpoint,
you
know
either
we
we
keep
it
as
a
long-lived
draft
or
we
instantiate
it.
Some
way
ask
the
RFC
Editor
to
do
it.
That's
a
very
different
process
than
going
out
to
the
ietf
community
and
saying
okay.
Ietf
last
call
time
wait,
wait.
H
Yeah,
so
Paul
raises
an
excellent
point:
the
reason
that
we
might
publish
in
terms
of
an
Roc
for
something
like
this
is
because
we
think
this
is
well.
We
might
we
might
do
it
for
any
number
of
reasons,
but
my
my
impression
is
that
what
we
would
want
to
do
as
a
result
of
that
is
this-
is
memorializing
the
consensus
of
this
group
that
this
is
a
good
thing
and
we
would
like
to
solicit
input
from
all
these
other
groups.
H
We
can
also
ask
for
input
from
all
these
other
groups
if
we
think
that's
important
here
at
different
places,
but
I
don't
think
that
this
is
what
we're
intending
to
do
with
this
particular
document,
because
this
is
just
like
documenting,
what's
in
the
code
right
now
to
the
to
the
greatest
extent
possible,
so
I
think
from
that
perspective,
where
it
stands,
is
probably
fine.
The
the
points
that
Robert
raises
about
change
and
how
we
deal
with
that
leads
me
to
all
sorts
of
other
conclusions
that
would
be
controversial
in
this
room.
H
Also
so
I'll
refrain
from
I'll
refrain
from
bringing
them
up
at
this
point,
but
I
think
we
really
do
need
to
consider
this
as
a
starting
point
for
for
addressing
some
of
those.
Those
latent
change
demands,
because
I
too
want
full
names
and
I
I
too,
want
to
deal
with
things
like
the
U
element
that
are
terrible
and
have
changed
recently.
H
M
I
My
speaking
is
still
up.
There
might
be
good
enough
in
the
analysis
that
you
were
just
skimming
Martin.
Do
you
have
an
assumption
that
we
will
republish
the
rscs
that
have
been
published
in
the
there
is
nothing
that
documents
what
the
grammar
those
things
have
been
published
in
in
some
future.
Yes,
this
is
really
the
approved
grammar.
B
H
Yeah,
so
to
to
the
extent
possible,
John
has
managed
to
capture
what
what
it
is
implemented
in
the
in
the
current
implementation.
I
think,
that's,
probably
probably
correct,
there's
a
bunch
of
things
that
have
been
added
to
the
format
since
seven
nine
on
one.
There
are
a
bunch
of
things
that
have
subtly
changed.
All
of
those
should
largely
be
in
there
I
again,
it's
pretty
close
and.
H
So
I
was
I
was
going
to
address
that
point
directly.
I
think
that
any
effort
that
we
undertake
here
is
probably
going
to
need
to
be
backwardly
compatible
in
the
sense
that
whatever
it
is
that
we
describe
tomorrow,
including
the
full
name
change
and
all
of
the
other
things
that
we're
talking
about.
It
probably
needs
to
document
those
thousand
or
what?
H
H
How
we
produce
that
I
think
is
is
a
very,
very
interesting
question
and
when
we
produce
that
is,
is
another
one.
I
think
some
people
are
looking
for
us
to
do
something
right
now:
sort
of
a
best
effort
attempt
to
ensure
that
something
goes
in
the
RFC
series
that
describes
those
thousand
plus
rfcs
that
have
been
published
in
XML
format
since
7991
that
don't
actually
use
7991.
H
L
It's
Elliott
so
I'm
trying
to
sort
a
Way
Forward
here
in
terms
of
how
we
can
proceed
and
I
think
Robert.
You
gave
a
good
example
of
something
that
we
could
probably
work
on,
just
as
a
way
forward
to
sort
of
act
as
a
forcing
function,
and
if
you
want
to
work
on
names
as
the
as
the
first
thing
or
whatever
you
want
to
work
on
is
the
first
thing
right
then.
What's
the
next
step,
do
you
write
a
short
draft
to
say
here's
what
I
want
to
do
about
names?
L
Do
we
write
a
long
draft
that
says
here
we
want
here's.
What
we
want
to
do
about
everything
and
one
of
those
things
is
names
and
I.
Think
if
we,
if
there's
the
boil
the
ocean
approach,
which
I
think
is,
is
the
latter
but
I
I
sort
of
like
the
idea
of
sort
of
knocking
these
things
down
one
by
one?
So
we
don't
so
we
can
get
things
fielded
faster,
a
little
bit
more.
You
know
agility
if
you'll
pardon
these.
L
The
term
question
is,
then,
how
does
the
whole
schema
look
in
the
process?
So
maybe
what
we
need
to
do
is
break
these
things
into
two
different
problems:
right,
there's
the
schema
and
the
versions
of
the
schema
which
may
or
may
not
be
an
RFC
I
I'm,
beginning
to
think
it's
not,
and
then
there
are
the
changes
to
that
schema
which
are
documented
in
rfcs
and
that
allow
for
small
incremental.
L
C
E
I
agree
with
the
slide:
I
think
the
hard
part
is
getting
consensus
because
not
everybody
is
happy
about
this
document,
but
the
whole
purpose
is
just
documenting
it
I'm
not
saying
this
as
an
ibtrib
member,
but
like
we
don't
have
to
publish
it
in
this
group.
If
you
just
want
to
document
it,
we
can
also
publish
it
somewhere
else,
so
it's
updating
an
IEP
document.
So
this
is
still
enough
for
that
stance.
C
O
I
I
think
that
they're
actually
useful
there,
because
they're
extractable
and
stuff,
like
that,
so
I
wouldn't
take
them
out.
We're
talking
about
four
things
right
here
and
there's
a
few
more
presentations
that
are
on
these
four
things.
So
I'm
not
sure
what
to
say.
But
I'm
hearing
some
people
say
this
when
what
they
aren't
actually
talking
about
is
just
the
as
implemented
draft.
It's
this
plus
everything
that
comes
in
the
future.
B
B
So
whatever
we
so
whatever
we
do.
I
think
we'll
take
some
time
to
get
to
a
document
which
has
consensus
and
I.
Don't
understand
quite
understand
how
we
could
publish
this
current
document
and
then
like
Deltas
with
rfcs,
because,
like
the
pieces,
you're
dealting
against
don't
consensus.
That
seems
very
confusing,
so
so
I
think
like
again,
I'm
not
like
that
does
not
take
a
position
between
RFC
or
not,
which
I
think
is
a
separate
question.
What
I
think
is
more
relevant
the
question
that
should
be
an
RFC
is.
B
Unfortunately,
some
my
point
is
a
maintenance
mechanism
for
this
document.
Even
if
we
like
say
congratulations
to
all
those
is
document
everything,
because
that
was
like
that.
Quite
that
simple
and
so
so.
I
think
that,
but
that
long
change
of
reasoning,
I
think
leads
me
to
like
maybe
better
to
be
an
idea
in
RC,
but
but
I
think
I,
guess
what
I
really
wanted
to
say
was
I
think
we're
going
to
need
a
maintenance
mechanism
or
some
kind
of
the
document,
even
though
maintenance
is
well,
hopefully
relatively
small.
A
Lawrence
yeah
I
think
I
agree
with
lots
of
what
Echo
and
others
have
said
so
so
I
think
we're
focusing
way
too
much
on
publishing
rfcs,
especially
if,
if
so
so,
those
rfcs
that
are
the
as
is
are.
They
are,
as
its
documents
right
they're
like
internal
working
documents
that
we
write
for
ourselves
to
make
sure
we're
all
aligned
right
and
and
as
long
as
that's
the
case,
they
never
need
to
see
RFC
publication.
Frankly
right,
they
might
for
historic
reasons.
A
That
was
the
quick
specification
which
we
occasionally
snapshotted
to
a
submitted,
ID,
right
and
and
that
process
I
think
worked
well
for
quickly.
It
might
work.
Well
for
this
year,
because
it
looks
like
we're
going
to
have
a
whole
bunch
of
individual
things
that
are
in
flux,
that
need
separate
discussion
and
or
Pawn
resolution
might
then
lead
to
a
merge
into
the
common
agreed
on
working
document
right,
I.
D
Hi
Mike,
St,
Johns
I
think
we're
starting
to
to
hit
the
limits
of
what
we
can
do
with
our
season.
This
particular
piece
of
it
it's
sort
of
The,
Meta,
Meta,
Meta,
piece
of
it
that
we're
dealing
with
here
we
need.
We
need
a
document
that
that
authors
can
Implement
can
can
Implement
rfcs
against.
We
need
a
tracking
of
what
the
code
base
is
doing
at
any
given
particular
point
in
time
and
at
some
point
in
time.
D
Those
need
to
merge
in
some
way
shape
or
form,
and
we
need
a
history
so
that,
if
somebody
picks
up
an
RFC
10
years
down
the
line
and
sees
tag
foobar
and
they
can't
find
a
document
that
explains
what
tag
Fubar
is
all
about.
You
know:
we've
failed
there.
So,
with
respect
to
this,
I
would
actually
support
publication
as
a
as
built.
D
Here's
the
trans,
hands-off
Handover
from
the
pre-race
to
the
post,
rsce
get
that
down
and
then
figure
out
what
we're
going
to
do
in
this
group
with
respect
to
the
the
cracking
going
forward,
and
it
may
be
that
we
actually
do
something-
that's
more
along
the
lines
of
a
beta
test
model
where
we
release
the
new
things
to
a
limited
number
of
people
we
test
them
out
before.
We
then
actually
incorporate
them
into
the
whole
system
anyway,
I.
D
C
M
But
I
do
think
it's
important
to
somehow
establish
a
starting
point,
which
largely
agrees
with
my
suggestion,
I
think
of
where
of
where
we
are
now,
whether
that's
an
RFC
or
some
other
sort
of
document,
and
not
certain
I
care.
But
it's
it's
very
important
to
be
statement
and
and
as
part
of
the
stability
issue.
M
I
would
like
to
understand
something
which
has
never
been
revealed
to
me
today,
which
is
the
what
the
places
which
are
storing
copies
of
the
RFC
series
on
the
basis
that
it
proves
their
archival
of
Nature
and
accessibility.
Think
they
agreed
to.
Are
they
storing
PDF?
Are
they
storing
text?
Are
they
storing
them
out
if
they're
starting
XML?
What's
their
tolerance
of
change
and
I?
Think
understanding
that
stuff,
unless
we're
going
to
drop
yard
today
is
very
important?
I,
don't
think
we
know
thanks.
F
F
M
F
At
the
time
last
time,
I
talked
to
them
that
question
hadn't
come
up,
I
mean,
but
I
I
can
talk,
but
you
know
it's
like
it's
something
worth
addressing,
but
documents
that
go
through
multiple
versions,
even
even
very
minor.
Multiple
versions
are
not
unusual
in
the
world
and
this
should
not
be
an
insoluble
problem.
M
It's
not
an
insolutable
problem,
but
understanding
whether
it
is
possible
for
somebody
to
easily
obtain
a
copy
of
an
RFC,
as
that
RFC
existed
on
such
a
particular
date
is
different
from
being
able
to
obtain
a
copy
of
whatever
the
iatf
thinks.
The
RFC
is,
if
that's
changing
and
several
comments
which
are
made
today.
Many
of
the
comments
that
we
go
to
list
say:
well,
we
just
changed
them,
update
them
or
replace
them
with
the
current
format
or
whatever
the
issues
are
and
and
that's
where
the
concern
lies.
C
So
this
is
Pete
Resnick
and
asking
from
the
floor.
I
could
formulate
this
as
a
chair
question,
but
it
seemed
easier
to
do
it.
Just
as
a
participant
I've
noted
in
the
chat
room.
There's
this
distinction
between
how
we
publish
what
form
of
documents,
how
many
documents
and
when
we
publish
so
do,
we
need
to
publish
an
RFC
now
and
then
one
later
do
we
publish
all
at
the
same
time.
So
one
of
the
questions
that
keeps
coming
into
my
head
is
for
the,
as
is
document.
C
Is
there
a
need
for
that
to
be
fixed
at
any
particular
time,
so
the
discussion
of
for
purposes
of
documenting
history?
So
people
can
recreate
what
the
current
set
of
documents
has
as
a
syntax
is
important,
but
I
don't
see
that
as
needing
to
happen
now?
Is
there
a
purpose
for
the,
as
is
document
to
be
fixed
now
or
do
we
have
a
deprecated
things
that
happened
over
the
years
section
in
whatever
policy
document
we
come
up
with
that
expresses
what
we
have
consensus
to
go
forward
with
foreign.
I
C
I
Foreign
just
like
to
follow
on
to
the
a
comment
that
that
Mike
made
the
idea
that
we
would
need
something
that
somebody
could
refer
to
10
years
from
now
to
pick
up
and
and
do
something
that
would
be
the
final
product
of
whatever
we
write
right
and,
if
we're
still
working
on
that
10
years
from
now,
I'm.
Very,
very
sad,
the
so.
I
The
the
just
keep
in
mind
that
as
we're
whatever
we
do
as
we're
going
along
that
that
mythical
some
large
number
of
years
in
the
future
person
has
to
be
able
to
answer
that
question.
And
if
there
is
a
you
know
an
active
process
around
a
document
that
can
be
pointed
to
you
to
answer
that
question
great
otherwise
put
down
something
in
the
fossil
record.
E
Yeah
I'm
actually
not
sure
what
it
would
do
with
the
document
anymore.
Then
I
was
beside
that,
like
I,
don't
think
it's
worse
to
have
this
discarded
any
longer.
It's
been
a
hard
time
on
that,
but
we
need
a
conclusion,
but
I
wanted
to
comment
on
some
things
about
process
that
I
heard
so,
like
my
expectation,
is
not
that
we
will
ever
reach
the
state
where
we
would
not
be
needed
to
do
small
changes
right
and
we
have
a
process
for
that.
E
Unfortunately,
if
even
if
you
don't
like
it,
the
process
is
that
the
rsap
can
decide
on
on
things
that
need
to
be
cited,
timely
and
then
we
have
more
time
here
to
actually
figure
out.
What's
the
policy
behind
that
right,
we
have
that
process
it's
already
there.
It
was
also
a
comment
that
we
need
to
have
some
documentation
about
what
the
current
tools
does.
That's
also
good.
It's
also
not
for
this
group.
C
O
O
What
I'm
talking
about
yeah.
So
what
I'm
talking
about
here
is
assuming
that,
whatever
this
draft
that
John
has
which
describes
how
the
tool
works
now
is
published
or
solidified
somewhere,
we
know
that
there's
still
work
to
do
this
proposal
is
and
I'm.
Sorry,
let
me
let
me
just
give
the
reasons.
Some
of
the
things
that
are
in
the
current
document
are
known
to
be,
or
possibly
bad
ideas,
things
that
really
should
be
fixed
before
we
do.
You
know
like
we,
we
just
get
up
and
walk
away.
O
Some
of
the
things
that
were
in
7991
were
removed
that
we
may
want
to
put
back
in.
They
were
removed,
for
whatever
reason
we
may
want
to
put
them
back
in.
So
we
need
to
do
something
and
I'm
calling
this
temporarily.
3.1
version
3.1,
where,
as
implemented,
you
can
think
of
as
3.05
or
3
x,
John
I
think
you
called
it
three
plus
plus
something
like
that
where
this
is
beyond
that
next
slide,.
O
Little
picture
time,
okay,
so
the
bad
ideas
that
are
in
there
now
some
were
introduced
some
some
things
in
7991
in
the
fullness
of
time.
We
realize
these
were
bad
ideas;
they
should
not
be
done
in
the
future.
Some
of
them
were
things
that
were
added
during
the
implementation
of
7991,
with
no
Community
review
or
consensus,
which
we
realize
now.
Those
are
bad
things.
We
don't
want
them
there
now
next
slide.
O
O
But-
and
this
is
what
a
lot
of
the
mic
line
for
the
last
half
hour
has
been
anything
we
do
here,
need
you
know,
the
first
thing
is,
it
needs
to.
You
know,
change
in
the
tooling,
and
that
can
be
done.
That's
really
not
a
hard
thing,
but
I
believe
from
what
a
few
people
said,
and
certainly
what
I
have
believed
is
someone
who's.
Looking
at
a
chunk
of
XML
should
be
able
to
tell
how
to
process
that
chunk
of
XML.
O
If
they're
looking
at
the
text
or
the
HTML
or
the
PDF,
they
don't
need
to
know
how
they
got
there,
but
if
they're
looking
at
the
XML
I
think
it
would
be
useful
if
we
have
multiple
ways
of
processing
XML.
For
somebody
to
say
that's
the
one
could
be
the
RFC
could
be
the
internet
draft,
whatever
next
slide
foreign,
and
then
we
get
to
the
question
of
archival
I'm
not
going
to
try
to
answer
it.
O
We
should
be
doing
anything
that
limits
what
that
means
now,
until
there
is
a
consensus
for
how
how
do
we
reach
archival
and
as
a
great
example
that
Martin,
you
said
that
you
expect
all
of
the
you
know
future
changes
to
be
Backward
Compatible,
that's
not
a
given
and
Robert,
unfortunately
jumped
on
that
and
said.
Okay
that'll
be
easy.
If
we
do
this
and
this,
but
if
we
don't,
we
have
this
whole
other
way
of
doing
things.
O
So
those
kind
of
decisions
need
to
be
made
explicitly
before
we
do
anything
like
what
I'm
suggesting
here
as
a
3.1
right,
we've
got
the,
as
is
we've
got
the
simple
things
that
are
pretty
much
straight
out
of
what
we
expected
from
7991,
and
then
we
have
this
whole.
Other
thing
of
you
know
what
it
would
be
nice
if
blah
blah
those
can
be
done
later.
I
think
what
we
should
call
or-
or
we
don't
need-
we
can
call
it
whatever
we
want
to
think
about
as
is
and
a
3.1
or
something
like
that.
O
That
is
simply
what
we
meant
and
what
we
would
have
meant.
If
we
had
known
that,
we,
you
know
weren't,
making
mistakes,
publish
that
in
the
same
way
that
we
are
publishing
as
is
and
then
move
forwards
and
I.
Think
that
was
it,
oh
okay,
so
that
was
the
pro
I'm.
Sorry
I
just
gave
the
proposed
ways
forward
and
then
one
way
to
do
the
3.1
is
to
have
an
explicit
set
of
differences
and
then
go
through
one
by
one
and
say
yes,
we
want
that.
No,
we
don't
want
that
for
the
no.
O
We
don't
want
thats
that
are
from
7991.
We
document
that
we
say
if
you're
reading
this
at
the
same
time
a
7991
we
explicitly
took
this
out
and
maybe
even
give
a
reason
and
the
reason
is
not
the
implementer
of,
as
is
decided,
they
didn't
like
it.
It's
a
community,
this
community
or
The
Wider,
Community
consensus,
find
rough
consensus
and
then
say
boomf
and
not
even
think
about
what
is
archival
until
we're
done.
I'm.
Sorry,
not
even
finalize,
obviously
we're
all
thinking
about
archival,
not
finalize,
so
that's
what
I've
got
all
right
me
up
here.
O
F
J
J
You
yeah
I
mean
yes,
there
are
some,
but
you
know
I
I,
edit,
all
my
stuff
in
Word
right.
If
anybody
who
wants
a
Windows
XML
to
RFC
I've
got
one
of
those
and
you
can
use
Mountain
down
as
well.
So
you
know
for
me.
It's
just
tell
me
what
the
XML
you
want
and
I'll
change.
My
tooling
and
you
know
every
I
think
everybody's
using
what's
his
name's
carsten's
till
for
markdown.
So
you
know,
you've
only
got
two
points
and
you'll
get
70
of
us
along.
C
N
Thanks
so
Paul
I'm
slightly
confused
by
something
two
slides
back
the
thing
about
the
version
we
need
to
say
in
the
next,
an
adult
and
which
grammar
is
used.
We
have
the
version
attribute
of
the
RFC
element.
The
problem
is
that
we
only
have
one
thing
defined
as
three
that
we
all
know
is
actually
3.1.
So
it's
not
that
the
XML
cannot
do
it.
It's
that
what
the
XML
do
does
we
do
not
have
the
right
thing
to
point
to?
O
N
I
I
don't
think
it's
that
complicated,
because
there
is
nothing
implemented
using
7991,
so
every
RFC
that
has
been
published
uses
whatever
the
new
stuff
is.
So
it's
simply
a
question
of
redefining
three
to
be.
What,
yes,
is
the
current
position,
because
nothing
has
ever
been
published:
yeah,
yes
under
three,
so
so
we
need.
C
H
H
I
think
the
the
notion
that
Paul
has
here
on
this
slide
is
is
kind
of
a
little
dangerous
I.
Think
if
you
put
a
version
4
in
the
document,
a
version
3
process,
it
would
refuse
to
process
it,
and
we
probably
don't
want
that
because
we
want
to
retain
some
amount
of
backward
compatibility
as
I
talked
about
before.
So
this
idea
that
you
have
some
way
of
identifying
which
tool
to
use
is
fragile
and
I.
H
Don't
think
that
really
gives
the
the
people
who
are
producing
XML
documents
as
input
to
our
process,
it
doesn't
do
them
any
favors,
but
I
do
think
that
Paul's
overall
approach
is
probably,
unfortunately,
despite
the
fact
that
it
is
so
much
work.
The
best
approach
that
we
have
here,
which
is
to
to
look
at
what
we
have
now
to
look
at.
What
we
had
then
do
a
do.
A
diff
go
through
each
one
of
them
and
make
sure
that
we
want
what
we
have
now
and
and
then
commit
to
that
I.
H
Don't
think
we
need
an
iotf
last
call
or
any
of
the
other
sort
of
rsab
processes
until
we're
certain
that
we
want
to
engage
with
those
processes.
But
I
do
think.
We
should
periodically
check
in
to
see
that
we're
not
completely
off
the
rails
in
that
process
and
that's
something
that
I
think
the
chairs
can
probably
work
through
for
us.
H
M
D
D
Xml
to
say
this
is
the
schema
designed
to
render
this
particular
thing.
Okay,
so
that,
let
me
finish:
okay,
the
the
key
point
is
that
the
document
that
explains
XML
schema
for
humans
isn't
necessarily
the
document
that
we
care
about
with
respect
to
the
archival
storage
piece
of
it.
So
that's
it
so
yeah
yeah,
so
so.
H
Mike,
the
the
thing
that
the
documents
contain
at
the
moment
is
there
is
a
comment
added
by
XML
to
RFC
that
identifies
its
own
version
and
transitively.
You
can
look
up
that
version
and
find
the
exact
schema
that
was
used
now
you
don't
that
that
schema
is,
is
a
machine
processable
thing
it
doesn't
contain
a
description
of
the
semantics
of
the
fields
and
how
it
was
interpreted.
But
if
you
look
at
the
code
for
that,
so
it's
there.
Currently
it's
a
little
imperfect
I
guess,
but
but
it's
pretty
reliable,
I
think
yeah.
Sure.
D
D
B
Ecker
yeah
from
the
floor,
so
I
just
like
about
taking
a
position
on
sort
of
the
exact
thing
that
Paul
suggested
it's
important
to
recognize
that
there
are
two
different
standards
for
the
Aziz
document
and
this
3.1
document.
The
server
for
the
address
document
is
as
closely
as
possible
or
Flex
what
the
tool
actually
does
and
because
the
one
thing
we
know
with
some
level
of
certainty
is
the
dot.
Is
it
the?
B
Is
that
the
tool
correctly
process,
the
XML
documents
that
we've
already
published,
published
and
so
well
I
mean
one
version
of
the
tool
data
which
would
developes
in
the
first
place
and
and
the
standard
of
and
the
standard
for
the
3.1
things
such
as
it
is,
is:
do
we
actually
like
the
stuff?
That's
in
this
grammar
as
opposed
to
is
this
correct
and
so
I
think
we
do
need
some
kind
of
process,
for
we
do
some
kind
of
process.
B
It
sounds
like
from
the
Xena
Martin
and
Julian
for
going
through
the
as
this
document
and
confirming
the
belief
that
everything
in
there
accurately
reflects
the
tool
and
I
don't
know
if
we,
it
was
called
for
that.
Frankly,
I
don't
think
we
probably
do
because,
like
as
far
as
I
can
tell
by
four
people
who
actually
you're
like
we're
gonna,
do
this
work
and
again,
like
I'm
sure,
we'll
find
later
some
things
where
it's
accurate,
we'll
have
to
fix
those.
B
But,
like
the
point,
is
these
accurate
as
possible
so
I'd
like
to
get
through
that
part
as
fast
as
we
can
and-
and
you
know,
I
think
you
know
when
I,
if
I
heard
Martin
and
Julian
say
they
were
pretty
happy
and
I
thought
it
was
accurate,
like
I'd,
feel
pretty
good
about
that
I'm.
Not
sure
Hulse
is
like
really
going
to
do
that:
I'm,
not
homosexual.
You
said
and
I'm
assuming
John's
already
happened
with
others.
B
He
wouldn't
have
you
know
because
he
just
said
so
earlier
and
then
I
think
you
know
and
I
think
we
do
have
to
go
through
this
process
that
some
process,
the
kind
that
Paul
indicated
of
going
through
each
Delta
and
and
forming
an
opinion
with
like
those
dolls
over
or
not.
But
then
but
I
think
the
starting
point
ought
to
be
like
convincing
ourselves
to
some
level
of
certainty
that
this.
The
current
document
is
like
is
an
accurate
description
in
a
non-normative
sense.
N
I
just
want
to
go
back
to
the
schema
and
syntax
comment
earlier
from
Mike
and
things
when
a
an
XML
document
is
published,
schema
no
longer
matters,
because
you
know
at
that
point
we
make
an
explicit
guarantee
that
we
have
validated
that
document
against
that
schema.
That's
it's
the
final
product.
It's
done
it's
there
and
when
someone
parses
that
they
don't
need
the
the
schema
to
do
that
with
they
just
parse
it
as
XML.
That's
the
purpose
of
XML.
N
So
that's
the
bit
that
we
need
to
make
sure
we
do
is
maintain
the
a
consistent
semantics
about
the
use
of
these
elements,
and
if
there
was
one
way,
I
think
that
we
would
determine
when
we
do
a
major
change
version
change
from
three
to
four.
It's
when
we
break
the
semantic
meaning
of
certain
things,
so
that
that's
a
very
clear
indicator
to
people
that
that
changes.
C
O
O
Have
this
really
good
idea
and
people
agree
that
it's
really
a
good
idea,
and
then
you
never
finish
and
by
the
time
you
do
finish.
The
fourth
good
idea
actually
con
contradicted
the
second
one
and
you
didn't
notice
it
so
I
want
to
emphasize
that,
but
to
also
to
talk
to
what
Jay
just
said,
even
though
the
schema
can
be
ignored.
We
in,
however,
we
did
7991
and
Friends
assumed
that
the
schema
and
the
semantics
were
intimately
tied.
I
don't
want
to
see
that
break
happen.
O
B
Two
things
from
chair:
one
we're
going
to
close
the
mic
line
very
soon,
because
we're
running
out
of
time
two.
If
anybody
obviously
hearing
General
positivity
about
Paul's
proposal
to
do
you
know,
serve
a
3.1
that
is
kind
of
like
a
consensified
version
of
three
point
of
the
current
thing.
If
anybody
would
like
to
speak
to
Jumping
directly
to
like
a
substantial
remake
of
this,
it
is
not
necessarily
not
compatible
like
Now's
the
Time
to
be
in
the
microphone.
E
L
Yeah
I
was
actually
thinking
very
much
along
the
lines
of
miria,
but
I
was
going
to
put
a
more
a
a
finer
point
on
it,
which
is:
can
we
in
order
to
get
through
this
process?
Is
it
possible
to
bring
to
bear
some
RPC
resources,
as
well
as
some
tool
teams
resources
so
that
we
can?
We
can
start
to
to
quickly
close
on
the
that
3.1
dock
so
that
we
can
move
things
forward
relatively
quickly.
D
P
So
I
apologize
I
had
a
conflicting
meeting,
so
I
missed
most
of
this,
but
I
do
think.
People
were
saying
that
I
may
have
had
positions
and
I
want
to
clarify
that
I
I
don't
have
a
problem
with
publishing
and,
as
is
you
know,
as
it's
implemented
document
I
think
that's
probably
a
useful
and
necessary
thing,
because,
right
now
the
state
of
things
is
pretty
bad.
What
I
have
a
problem
with
is
if
that
document
is,
is
portrayed
as
something
that
is
not
it.
It
is
not
the
process.
P
P
As
long
as
we
do
that
I'm
cool,
what
I
really
don't
want
to
happen
is
is
to
use
people
to
use
that
publication
as
an
excuse
to
say,
oh
well,
we
can't
consider
this
or
or
we're
done
now
or
we're
not
interested
in
this
I
think
we
do
need
to
have
a
separate
conversation.
I
I,
don't
think
you
know
we
can
do
more
than
one
thing
at
a
time
we
can
gather
issues
on
and
have
a
discussion
in
the
background
of
what
else
we
might
do
in
the
future.
It
just
shouldn't
impact
this
document.
C
Yeah
I
think
some
of
what
you
said
might
be
Obe
from
what
was
discussed
earlier
but,
as
I
said
before,
I
think
Ecker
and
I
need
to
kind
of
put
our
heads
together
and
summarize.
The
issues
that
we
heard
come
out
of
this
after
John
gets
the
minutes
out,
but
yes,
I
I.
What
you
said
makes
sense,
there's
a
couple
of
bits
that
I
think.
Probably
everybody
agrees
to
now
that
didn't
maybe
I'm.
I
You
know
if
I
don't
blow
anything
up.
I
have
to
vehemently
disagree
with
a
strong
point
that
Paul
made
at
the
mic
a
moment
ago,
which
is
the
no
we're
not
going
to
consider
any
new
things
until
we
get
all
the
way
to
the
3-1.
All
right,
that's
untenable.
We
just
cannot
do
that.
We
have.
We
have
maybe
you
weren't
here
at
the
beginning
of
the
meeting
I'll
Pony
up
the
the
question
of
the
yes.
I
O
O
C
Okay,
we
are
a
few
minutes
till
end
of
time,
so
plan
of
action
here
a
lot
was
said
here
that
I
think
needs
to
be
analyzed
and
down
to
what
points
people
were
making.
So
John
will
put
out
his
notes,
we'll
get
those
out
on
the
list.
Please
make
corrections,
as
you
see
appropriate,
we'll
finalize
some
minutes,
but
we'll
also
come
up
with
sort
of
a
an
issue.
C
Summary
I
think
so
that
if
anybody
disagrees
with
our
analysis
of
the
issues,
they
can
give
a
Yelp
and
then
we'll
try
and
start
making
some
calls
on
the
list
for
ways
forward.
This
was
incredibly
enlightening
and
helpful
to
me,
so
it
crystallized
a
bunch
of
issues,
anything
else
any
other
business,
since
we
do
have
three
minutes
left.
C
C
L
I
did
ask
so
on
the
list:
I,
no
I,
guess
I
asked
to
the
chairs
and
I
and
I'll
ask:
can
we
consider
the
tempo
in
which
we're
working,
I
I
think
we,
you
know
you
hear
Robert's
desire
to
move
forward.
I
think
my
desire
to
help
you
know
if
if
we
want
to
do
this,
as
is
to
try
and
get
this
closed,
I
I
I'd
ask
as
a
stream
manager
I'd
ask
that
we
take
a
certain
amount
of
alacrity
towards
how
we're
doing
things
and
if
it
means
interims,
it
means
interims.
L
But
let's
not
you
know,
let's
try
and
Advance
work.
I
think
everybody
here
has
a
lot
of
pent
up
energy
and
I:
don't
want
to
lose
that
energy
in
terms
of
of
the
you
know,
waiting
for
months
and
months
on
analysis,
so
let's
figure
out
some
some
modes
of
work
that
that,
where
we
can
rapidly
move
forward,
I
won't
get
into
details
as
to
how
I
don't
even
know
what
they
are.
But
I'd
ask
the
chairs
to
take
that.
C
Off
no
I
I
appreciate
that,
and
you
know,
my
schedule
has
been
funky
prior
to
this
and
after
my
holiday
next
week,
I
I've
got
times
so
I
will
commit
to
getting
together
the
summary
of
this
week
after
next
and
then
after
a
little
bit
of
discussion
on
the
list.
Let's
figure
out,
if
we
need
an
interim
we're
going
to
have
in
just
a
few
weeks,
probably
close
to
a
month
where
assorted
people
disappear
from
Earth
for
assorted
holiday
thing.
L
Thanks
Pete
just
to
follow
up
and
also
to
consider
what
resources
you
need
right,
what
resources
we
need,
whether
Alexis
can
help
in
this
regard,
Robert
what
resources
you
either
need
or
can
bring
to
bear
in
order
to
help
move
us
to
conclude
that,
as
is
as
quickly
as
possible.
I
don't
want
to
stalling
on
on
that
for
too
long.
So
as
much
as
we
can
identify
what
we
need
right.
G
A
Speed
and
flexibility,
because
if
we
don't
have
that,
we
might
end
up
in
situations
where
things
escalate
from
the
RPC
side,
right,
for
example,
on
names
right.
What?
If
we
have
an
author,
it
refuses
a
document
to
be
published
with
what
they
consider
an
incorrect
name
for
them,
but
that
would
then
require
the
rsap
to
take
action
and
punt
it,
and
it
would
make
it
complicated.
So
speed
and
flexibility
will
save
us
from
a
lot
of
these
pains.
C
So
that
was
another
question
that
I
had
now
we're
one
minute
over,
which
is
it?
Do
we
have
some
mechanism
for
this
group
to
deal
with
something
that
is
less
than
an
emergency
that
are
that
rsab
just
has
to
deal
with,
but
we
can
do
some
sort
of
short
Community,
Last
Call
on
a
decision
needs
to
be
made
here
and
I.
Don't
know
what
the
answer
to
that
is.
A
A
B
I
read
9280
and
someone
contradiction
if
I'm
wrong.
The
rule
is
that
we'd
have
to
publish
like
an
RFC
and
maybe
I,
think
I
think
if
the
rsat
finds
us
something
to
make
a
lot
of
math
decisions
that
may
be
ratified.
That
really
should
be
ratified
by
us.
Then
what
the
Rev
9280
to
make
that
possible.
Okay,.
N
Just
to
add
it's
not
emergency
or
non-emergency,
it's
is
there
something
in
the
current
policy.
The
current
rfcs
that
needs
interpreting
you
know
so.
I
I,
don't
believe
the
rsap
has
the
ability
to
add
a
new
element.
For
example,
that's
not
interpreting
a
policy,
and
so
some
stuff
just
falls
in
the
Gap
in
that
it
could
be
urgent
and
require
something
new
and
therefore
it
has
to
follow
the
rswg
process.
Even
if
that's
going
to
take
some
time.