►
From YouTube: IETF114 RSWG 20220725 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
E
D
Yes,
clinton
right
welcome
to
rswg
if
you're,
not
especially
rswg,
go
go
somewhere
else.
I
guess
come
in
the
next
slide.
Do
I
do
that.
D
So
yes,
so
there's
some
confusion
about
exactly
what
noel
should
be
shown
which
we'll
cover
later
in
this
meeting
for
the
purposes
of
this
discussion,
please
be
aware
of
the
note.
Well,
here's
slide
one
and
you
can
mentally
substitute
rswg
for
ietf
in
some,
but
not
all
of
these
sentences,
so
in
particular,
you're
still
consenting
to
the
ietf,
I'm
making
a
photographic
record,
apparently
as
opposed
to
the
rswg.
D
So
please
be
familiar
with
this
and
your
next
slide,
you
know
have
some
rfcs
which
again
may
or
may
not
apply.
So
assuming
you
understand
these
races,
I've
explained
them
to
you
we'll
move
on,
so
we
had
like
a
relatively
short
agenda.
D
You
know
this
got
formed
so
mostly
we're
hoping
to
just
sort
out
some
ground
rules,
so
we
want
to
talk
about
four
things:
sort
of
get
a
sense
of
what
people
think
you
know
the
scope
and
and
of
the
work
and
acceptance
criteria
are-
and
I
know
elliot-
had
posted
some
thoughts
outside
of
his
house's
criteria.
D
Let's
talk
about
some
logistics
with
everybody's
favorite
topic
being
github
a
cover.
Basically,
then
we
had.
F
D
Set
of
proposals
for,
like
you,
know
things
you
might
look
at
and
just
like,
make
sure
everybody's
aware
of
them
and
see
if
anyone
anyone
strikes
anybody's
fancy
and
really
want
people
to
want
to
work
on
it,
and
then
I
guess
all
their
business
in
case
there
is
a
business.
D
So
just
to
remind
you,
this
is
our
charter.
This
is,
in
fact,
pretty
much
the
only
description
of
what
our
scope
is,
but
the
key
word
here
is
policy
and
I
guess
members
of
the
community
and
collaborate.
So
this
is
just
like
background,
for
you
know
what
it
is
we're
supposed
to
be
discussing
next
slide.
D
I'm
sorry
with
that!
Oh
yeah!
Sorry!
Yes,
so
here
is
the
description
of
the
workflow
for
what
we're
supposed
to
be
doing,
which
looks
which
will
look
very
familiar
to
you
and
that
it
will
look
very
much
like
an
ietf
working
group
where
people
produce
proposals,
we
accept
adopt
them
and
then
eventually
you
know
we
refine
them
and
we
ship
them
out.
Is
there
a
second
slide
with
us,
or
this
is
the
first,
no
okay
right.
So
with
that
in
mind,
I
think
you
know
this.
D
Is
our
the
chairs
put
about
like
what
how
to
sort
of
drive
this
again?
So
if
someone
poses
some
new
work,
our
theory,
is
it
better
be
about
policy
number
one,
the
radius
of
enthusiasm
over
the
topic,
because
otherwise
we're
not
getting
anything
done.
D
We
think
we
have
some
kind
of
consensus
in
the
solution,
even
if
there's
not
consensus
on
the
proposal
itself
and
finally,
that
we
have
a
proposal.
That
seems
like
a
plausible
starting
point
and
again
this
is
just
like
me,
like
mirroring
all
the
crap
that
we
all
normally
do
in
a
nighttime
group
and,
of
course,
these
are
all
decided,
usually
by
rougher
people
consensus.
So
I
know
there's
some
discussion
on
the
list.
Does
anybody
think
that
this
is
like
a
bad
place
to
start
or
oh
robert?
Thank
you.
I
can't
see.
G
Hi
hecker,
I
just
wanted
to
ask
you
to
stay
closer
to
the
microphone
you're
fading
out
for
the
remote
people.
D
Okay,
well
about,
as
close
as
I
can
be
without,
like.
Actually,
I
see
all
right.
D
H
H
D
A
I
Elijah,
so
so
one
thing
that
came
up
earlier
today
in
with
the
rsap
is
that
there's
also
this
issues
that
might
arise
from
the
rpc
that
they
bring
to
the
rsap
and
the
rsep
decides
policy
work
needs
to
happen,
and
they
should
then
be
brought
here.
So
even
when
there's
no
enthusiasm,
you
got
to
do
something
occasionally
because
the
rpc
depends
on
it,
but
otherwise
this
is.
This
is
good.
D
J
All
right
now
wait
is
that
work.
Okay,
sorry,
it
always
makes
me
click
like
five
different
buttons.
I
kind
of
wonder
it
seems
to
me
we
might
be
able
to
take
some
of
the
heat
out
of
the
policy
versus
not
policy
issue.
If
there
were
a
mechanism
to
say,
okay,
that's
something
that
you
know.
We've
brought
to
the
community's
attention.
J
It's
not
policy,
but
it
can
go
to.
You
know
the
rpc
in
a
discussion
in
a
relatively
transparent
way
and
and
what
I'm
thinking
about
is,
I
think
it
was.
It
was
mentioned
earlier
on
about
having
an
issues
list
for
the
working
group,
and
you
know
so.
J
If,
if
we
have
an
issue,
we
say:
okay,
that's
something
that
we
would
like
to
improve,
or
that
you
know
it's
not
really.
You
know
pure
policy,
but
at
least
we
get
it
out
in
front
of
the
community.
The
rpc
can
hit
it
off
and
it's
not
something
that
you
know.
Somebody
says:
oh,
no,
you
should
just
go
talk
to
the
rpc
directly.
I
think
that
might
take
a
little
bit
of
the
heat
out
of
this
kind
of
zone.
If
that
makes
sense,
just
something
to
to
think
about.
E
Paul
hoffman,
so
many
working
group
mailing
lists
are
for
working
group,
work
plus
other
stuff.
That's
not
working
group
and
stuff
like
that,
and
that
can
get
really
messy,
but
also
it's
really
terrible
to
say.
No,
you
can't
talk
about
that
here
and
there's
nothing
else,
so
I'm
not
proposing
a
solution,
but
some
of
the
stuff
that
people
said
before
about
there
might
be
an
rpc
thing
that
comes
in
and
such
like
that
that
could
be
not
working
group
work.
E
That's
on
the
mailing
list
that
just
needs
to
be
looked
at
and
said:
okay,
we
know
that
that's
not
policy,
we
know
that's
not
happening
and
treat
it
like
a
normal
working
group
mailing
list
where
other
stuff
might
or
might
not
happen.
Having
said
that,
that's
a
really
attractive
nuisance
about
everything
in
the
in
the
rfc
editor
series.
So
I'm
not
saying
that's
a
good
idea.
A
So
so
let
me
show
you
the
next
slide
and
we
sort
of
anticipated
that
we're
going
to
end
up
with
some
sort
of
issue
tracker.
So
this
is
logistics,
but
I
think
it
goes
to
your
point
that
they're
going
to
be
sort
of
issues.
A
Looking
for
a
draft
looking
for
people
to
pick
up
and
champion
the
idea
and
gather
together,
some
thought
that,
yes,
this
belongs
here,
and
we
want
to
write
this
up
and
we
want
to
get
the
working
group
to
work
on
it
and
then
independently
we're
going
to
have
once
someone
proposes
a
draft
and
adopts
it,
which
is
really
the
main
portion
of
the
workflow.
As
stated
in
9280,
then
we're
gonna
have
a
draft
to
work
with
and
we'll
have
issues
on
that
draft,
as
the
working
group
goes
through
it
and
works
on
it.
A
So
I
think
yeah,
we're
gonna
have
those
issues
where
people
are
well.
We
should
think
about
what
this
is
and
whether
this
belongs
here
and
that
discussion
can
go
on
and
sort
of
have
that
as
a
parallel
track
to
oh
and
here's
the
work
that
we're
actually
trying
to
get
done
and
write
a
new
policy
for
does
that
sort
of
go
to
what
you
were
looking
at
paul
nods
is
that
up
and
down
miriam.
H
A
Good,
so,
with
regard
to
logistics,
like
I
said,
we
we've
already
seen
a
number
of
issues
both
in
the
form
of
drafts,
but
more
mostly
in
the
form
of
hey
here's,
something
I
think
this
group
might
work
on.
A
So
we've
been
talking
about
it,
we're
thinking
that
we
can
simply
use
github
as
the
issue
tracker,
but
we
are
not
led
to
that
either
way.
Discussion
of
any
of
the
items
takes
place
on
the
mailing
list,
but
we
will
need
some
sort
of
tracking
device
if
people
have
strong
feelings
about
it,
one
way
or
the
other
please
do
mention,
but
otherwise
we're
you
know
just
going
to
figure
out
what
feels
comfortable
and
go
ahead
and
do
that,
like
I
said,
it'll
end
up
on
the
mailing
list,
one
way
or
the
other.
A
So
if
there's
no
comments
on
that,
we've
got
the
list
of
things
that
people
have
brought
up
on
the
mailing
list
and
if
people
want
to
just
give
a
quick,
this
is
what
I'm
thinking
about.
This
is
what
I
think
needs
to
be
done,
and
you
are
present
in
the
room
except
robert
jumps
in
and
and
has
a
comment.
Robert
go
ahead.
G
No,
I
just
have
a
topic
that
I
wanted
to
call
out.
So
put
me
at
the
end
of
the
queue
after
the
people
that
are.
D
A
Sounds
good,
so
this
is,
do
we
have
a
second
yeah?
We
have
two
slides
of
this,
so
I'll
just
call
off
issues,
and
if
people
want
to
come
up
and
say
something
about
them,
please
do
paul.
Did
you
want
to
talk
about
the
the
documenting,
the
relationship
stuff,
just.
E
Super
briefly
because
it
should
be
on
the
mailing
list
and
right
as
we
could
see,
people
it's
complicated.
I
wanted
to
see
if
there
was
interest
it
seems
like
there's
interest.
There
may
be
interest
in
doing
it
a
very
a
different
way.
We
already
have
a
worked
out
example
from
earlier,
but
I
didn't
know
if
people
had
burnt
out
on
it
and
didn't
want
to
deal
with
it
or
want
to
deal
with
it,
and
I
got
the
feeling.
A
And-
and
I
mean
going
back
to
the
logistics
issue-
and
you
know
ecker-
and
I
haven't
talked
about
this
particularly
but
my
sense
is
you
know,
for
we
don't
have
a
draft
yet
we're
trying
to
figure
it
out.
Ecker-
and
I
are
here
to
moderate
that
discussion
and
and
sort
of
move
it
along,
but
it
doesn't
become
a
working
group
item
until
there
there's
an
agreed
pair
of,
or
you
know,
three
or
ten
authors
who
say
yeah
we're
going
to
work
on
this
document.
Put
the
draft
out
there
and
say
we
want
this
adopted.
A
So
we'll
we'll
manage
those
discussions,
but
you
know,
and
so
this
discussion
we
can
continue
on
the
list
until
you
all
decide.
Yep
we
want
a
draft
and
we
want
to
get
this
adopted
is
brian
in
the
room.
I
didn't
see
him
no
brian's
not
around.
Does
anyone
want
to
comment
on
brian's
proposal
with
regard
to
updating
and
versioning.
D
So
I
mean
this
was
basically
the
perennial
question
of
like
referential
integrity,
for
you
know
when
you
talk
about
sip
or
rfcs,
and
you
get
abyss
like
how
does
that
work?
And
how
do
you
know
do
you
have
standard
numbers
or
or
numbers
or
whatever?
So
that's
what
this
that's
what
this
topic
was
about.
So
I
don't
know
if
people
have
enthusiasm
for
is
there's
an
enthusiasm
for
that,
but
that's
what
this
topic
was
and
I
can
just
go.
D
I
mean
I
I
I
put
these
in
so
I
can
go
through
these
this
next
topic,
and
so
I
think
our
plan
is
basically
to
take
each
one
of
these
and
make
an
issue
about
it
and
then
and
and
and
then
I
think
you
know
allow
you
know,
allow
you
know
I'll,
probably
just
cut
and
paste
out
of
the
emails
that
introduce
them
so
that
we'll
have
a
description
and
then
you
know
paul.
If
I
don't
do
it
properly,
you
can
feel
free
to
like
out
of
the
issue
whatever.
D
So
this
next
topic,
in
fact,
was
something
what
miriam
was
just
talking
about,
which
is
and
pete
were.
What's
going
on
the
rswg
list
versus
the
rfc
interest
list,
then
these
next
two
are
there,
apparently
a
number
of
rfcs
that
are
either
in
an
unknown,
unknown
status
or
in
a
legacy
stream,
and
are
we
going
to
attempt
to
repair
that
and
if
so,
how
this
next
topic
is?
Apparently,
the
ieb
stream
is
not
chartered
with
his
bcps,
and
it
has
done
so,
and
so
we
have
to
manage
that
somehow.
D
So
these
three
are
all
like:
we
created
a
mess
in
the
past
and
do
we
care
next
slide
right
can
rfcs
be
on
more
than
one
stream.
D
I'm
not
sure
it's
natural,
it's
policy,
but
what
should
be
the
rc
email
announcement?
The
you
know,
there's
a
lot
of
questions:
the
boilerplate.
Whatever
this
author
ethics
point.
I
know
this
came
up
in
the
ietf
list.
Was
you
know
what
is
your
responsibility
as
an
as
an
rfc
author
and
a
draft
author,
if
you're
taking
what
someone
else
has
done
but
you're
not
you're,
not
making
them
an
author
in
your
document
in
terms
of
acknowledgement
or
whatever?
D
I
think
you
know,
especially
in
cases
where
you're,
essentially
just
taking
someone
else's
document
wholesale,
which
is
permitted
by
the
copyright,
but
maybe
not
by
maybe
not
by
better
practice,
a
topic
that
came
with
this
morning-
format
evolution,
I
think
you
know
the
more.
I
look
at
90
280,
the
more.
I
see
it
as
a
framework
for
creating
self-governance
rather
than
a
framework
for
self-governance,
and
so
you
know
we
didn't
actually
write
down
who's
responsible
for
actually
doing
the
pieces
of
format,
evolution
and
so
we'll.
D
If
we
want
to
have
the
format
evolve,
it
seems
to
me
probably
like
looking
at
it
personally,
it
seems
to
me,
nobody's
actually
empowered
to
involve
the
format
right
now
and
so
they're
working
paul.
You
may
want
to
disagree
so.
E
Often
I
read
9280s.
That
is
absolutely
part
of
part
of
of
this
working
group.
That
is,
it
is
policy.
What
what
is
an
rfc
is
policy,
and
since
you
know
the
the
format
is,
you
know,
how
does
the
rfc
exist
as
bits
on
on
disk
much
less
on
the
wire?
I
totally
thought
it
was
that
if
I
purposely
wasn't
involved
in
the
creation
of
9280,
if
it
wasn't
there,
that
seems
like
a
massive
oversight,
because
that's
one
of
the
pieces
of
work
that's
been
ongoing
for
years.
D
I
guess
my
sense
is
that
there
was
going
to
be
some
arguing
about
exactly
what
was
policy
was
mechanism
in
terms
of
like
so
this
worker
you'd
be
deciding
like
what
the
names
of
the
tags
are,
but
I
think
we're
certainly
empowered
to
direct
my
senses,
we're
empowered
to
direct
that
work,
but
exactly
how
we
divide
up
that
work
is
perhaps
the
question
that
needs
to
be
designed.
Michael,
I
think
robert
robert.
G
Yeah,
so
I
will.
G
Enter
into
that
conversation,
I
think
that
this
working
group
is
the
place
that
we
have
to
do
the
evolution
of
of
at
least
the
grammar,
and
probably
is
the
group-
that's
going
to
be
the
touchstone
on
dealing
with
some
of
the
technical
issues
like
if
we
decide
to
make
radical
changes
to
the
way
rfcs
are
presented
like
changing
out
the
css
entirely
for
the
way
the
rscs
are
presented
on
the
rfc
editor's
website,
for
example.
G
I
really
do
think
that
we
need
to
have
a
a
a
venue
that
is
consensus
based,
and
I
was
expecting
this
group
to
be
that
group
so
that
I
can
get
out
of
the
queue
I
will
bring
my
other
existing
topic
up.
You
can
add
it
to
the
slide
if
you
want
or
just
put
in
the
issue
tracker
later.
G
I
would
like
to
see
this
group
take
on
changing
the
policy
for
internet
graphs
and
the
rscs
to
allow
utf-8
throughout
the
document,
and
not
just
in
names.
K
L
Hey
good
afternoon,
everyone
and
good
evening
to
those
in
europe-
and
I
guess
I
think
it's
good
morning,
though,
to
those
who
are
down
under
in
in
australia
and
new
zealand.
L
L
Can
pass
judgment
on
whatever
it
wants
to
pass
judgment?
It
can
draw
the
line
of
policy
wherever
it
wants
to,
but
with
the
understanding
that
we
can,
we,
as
the
rswg
can
break
things
very
badly
for
everybody.
If
we,
if,
if
we
get
it
wrong,
so
we
should
just
choose
wisely,
but
it's
also
one
of
the
reasons
we
should
walk
and
not
run
in
this
process
and
try
and
just
step
through
you
know,
learn
as
we
go.
L
We
don't
have
a
lot
of
running
code,
which
is
say
we
have
none
in
the
in
terms
of
you
know
how
these
groups
operate.
You
know
you
saw
the
sort
of
fumbling
that
we
did
in
the
rsab
today
we're
going
to
do
more
of
that
as
we
get
through
this
process
and
we'll
just
have
some
patience
to
try
and
figure
out
how
to
draw
the
line
in
each
case,
all.
B
C
The
charter
isn't
a
charter,
it's
sort
of
a
statement
of
interest
and
it
may
be
worthwhile
to
spend
maybe
the
first
month
or
so
trying
to
say
what
we're
going
to
start
with
and
just
sort
of
get
a
basket
around
that
otherwise
we're
going
to
be
piecemealing
ourselves
out
into
a
lot
of
space,
and
we
won't
make
progress
on
anything
going
back
to
what
elliott
was
talking
about.
I
wasn't
saying
anything,
but
the
rsab
is
the
final
decider
on
whether
or
not
it's
policy
or
not.
C
L
Thanks
eric
and
thanks
mike
now
I'll
comment
sort
of
with
the
you
know
my
rsb
member
hat,
I
don't
think
that
policy
was
a
criteria
for
making
a
decision
if,
if
it
doesn't
break
the
stream-
and
I
don't
perceive
it
as
if
I,
if
I
don't
perceive
it
breaking
the
stream
or
breaking
the
long-term
interests
of
the
series-
that's
sort
of
the
the
the
measure.
L
I
think
those
are
the
measures
that
9280
states
and
those
are
the
measures
by
which
I
will
judge
something
in
the
you
know,
as
the
art,
with
my
rsap
hat
on
just
that's
my
own
personal
view
in
terms
of
how
to
interpret
9280-
and
I
just
want
you
guys
to
know
going
forward-
that's
that's
how
I'll
look
at
it.
C
Sorry
me
again
ellie
I
I
understand
where
earlier
it's
coming
from,
but
at
some
point
in
time
you
have
to
keep
this
group
from
basically
micromanaging
the
people
who
are
doing
the
publication
and
pieces
of
that
and
that's
why
I'm
saying
that
there
ought
to
be
some
discussion
about
where
that
line
is
drawn,
because
otherwise
we're
going
to
get
into
trouble
really
quickly.
A
So
mike,
I
tend
to
agree
with
you,
but
I
also
don't
think
we
have
to
be
too
theoretical
about
it
that
to
a
certain
extent,
as
the
discussion
develops
in
the
group
about
a
particular
proposal,
I
think
we
will
be
able
to
say
hey.
This
is
or
isn't
a
policy
question
for
these
reasons
and
then
develop
what
we
think
the
principle
underlying
that
is
as
we
go.
D
I
just
want
to
add
that
that
9280,
contemplates
and
in
fact
expects
that
the
rcb
members
will
participate
in
the
discussion,
and
so
I
would
hope
that,
as
we
have
these
kinds
of
individual
things
that
they
would
in
fact
say
you
know
well,
we
think
this
is
your
micromanaging
now
and,
like
my
rsv
hat
like
I
might
be
sad
about
that,
or
vice
versa.
E
Paul
hoffman,
so
one
thing:
that's
not
on
this
list
that
has
come
up
in
my
mind.
A
few
times
is,
as
we
are
doing,
policy
for
our
seas,
that
kind
of
slumps
into
policy
for
internet
drafts
it
certainly
co.
We
could
limit
it
to
the
last
internet
draft
or
or
the
internet
draft
that
gets
sent
to
the
rfc.
Editor
must
blot
a
blah,
but
then
everyone
knows
that
there
should
be
ones
before.
I
don't
have
an
answer
for
that.
E
I
know
that's
not
in
our
charter,
but
a
bunch
of
the
stuff
we've
talked
about
will
probably
slump
back
into
the
internet
draft
series,
whether
we
are
being
on
it
or
not.
Don't
know
how
to
do
that,
but
I
think
we
should
be
aware,
because
there
are
many
people
who
would
say
internet
drafts
can
do
anything,
don't
limit
us
there
largest.
I
Hey
last
I
got
now.
I
have
two
things
to
say
so
one
I
disagree
because
it's
the
isg
who
was
in
charge
of
the
internet
draft
in
the
format
right
and
so
and
so
there'll
be
blood.
I
guess
if
this
group
wants
to
go
into
that
space,
but
that
said
right,
our
inner
drafts
are
produced
using
the
same
tools
as
rfcs
and
therefore
there's
a
natural
bleed
over,
but
which
is
what
you
said
right.
I
So
we
gotta
sort
of
have
some
communication
and-
and
we
want
that,
but
policy
for
internet
drives
is
set
by
the
isg,
the
the
thing
I
actually
got
in
the
line
for
something
else
and
we've
been
talking
about.
You
know
this
group
does
policy,
but
it's
actually
doing
policy
for
the
series
right
and
specifically
in
my
mind,
that
means
this
is
about
the
the.
What
do
you
want
from
the
series?
I
D
I
mean
that's
how
I've
been
thinking
about
it.
Surfaces
I
mean
I
was
thinking
like
one
might
say,
you
know
we
want
the
rfcs
to
render
in
two
columns
and
we'd.
Let
like
robert
figure
out
how
to
do
it
like
css
did
it,
but
we
wouldn't
be
like
you
know
here.
It's
like
you,
know:
here's,
here's,
here's
where
to
use
css
grid
or
masonry,
or
you
know,
or
or
flexbox
gene.
F
Hi
there
gene
mahoney
and
I
am
putting
on
my
rpc
hat
and
saying
hey.
I
will
be
participating
in
this
working
group
and
providing
the
rpc
perspective
on
these
questions.
D
C
D
Was
good
probably
got
that
one
done?
The
other
two
items
that
exist
are
concern
about
errata
trolls.
This
is
brian
again.
Are
we
seeing
a
bunch
of
errata,
that's
sort
of
messed
up,
and
should
there
be
any
more
gateways
on
onorata
to
make
it
more
difficult
to
post
them?
I'm
not
taking
a
position
on
this,
I'm
I'm
merely
I'm
merely
noting.
This
is
an
item
that
came
up
and
the
final
item
is.
H
D
I
raised
earlier,
which
is
like
what,
if
anything,
we
didn't
need
to
do
the
wall
text
to
make
and
and
maybe
associate
rfc
is
to
make
it
properly
match
the
practices
we
have
here.
So
when
I
looked
at
the
noble
text
earlier,
I
noticed
that
basically,
it
seemed
to
have
three
broad
chunks.
One.
The
anti-harassment
policy
which
we
all
agreed
in
92
80,
is
that
we're
going
to
adopt
the
itf
and
investment
policy.
D
So
it's
merely
a
matter
of
doing
whatever
screwing
around
with
an
oel
to
make
it
properly
point
that
out
the
then
there's
the
ipr
sections,
which
it's
actually
9280
sort
of
an
admission.
It's
not
actually
saying
anything
about
whatsoever
and
that
may
be
sort
of
unfortunate,
but
presumably
we
have
to
since
we
take
since
we're
taking
the
so
we're
taking
things
into
our
drafts,
then
we're
presumably
expecting
the
boilerplate.
But
it's
worth
noting
that
it's
not
clear.
D
We
incorporated
the
patents
by
the
patent
on
thing
by
reference,
so
that'd
be
nice
to
work
out
and
then
finally,
there's
sort
of
the
material
about,
like
you
know
where
you're
consenting
to
being
photographed.
When
you
go
to
the
meeting
and
when
you're
like
you
know,
agreed
to
have
the
itf
process,
your
data
and
whatever,
I
suspect,
those
just
those
just
stay
as
long
as
you're,
an
itf
meeting,
because
it's
part
and
parcel
being
itf
meeting.
D
In
any
case,
I'm
not
saying
with
zelda's
now,
but
this
into
which
people
like
would
like
to
take
a
look
at
the
notewell
and
be
sad
about
it
or
such
revisions.
That
would
be
helpful
because
we
just
took
the
itf
one
for
the
moment.
D
And
with
that,
we
have
all
their
business,
which
may
be
nothing,
but
maybe
people
who
want
to
stand
and
speak
for
something
important
or
just
or
suggest
that
we
discuss
one
of
these
topics
in
more
detail.
G
A
A
So
if,
if
folks
think
that
that
is
an
acceptable
way
to
go,
we
do
need
to
work
out
with
the
secretariat,
because
this
is
a
broader
community.
You
might
want
to
attend
the
rswg
at
least
remotely
without
attending
the
ietf
meeting
and
paying
meeting
fees
that
we
may
need
to
work
out.
Something
to
have
that
happen.
But
beyond
that
the
logistics
seemed
we'll
meet
here.
I
I
Our
sub
members
should
actively
participate
in
the
working
group
right
which
we
are
trying
to
do.
However,
we
are
also
like
pretty
busy
during
the
week,
and
so
we
probably
have
created
a
little
bit
of
scheduling
nightmare
here,
because
you
need
a
whole
bunch
of
like
four
people,
ideally
right
that
own
the
stream.
So
if
one
of
us
isn't
here,
maybe
at
one
of
those
music,
it
doesn't
necessarily
mean
that
we're
not
interested
in
actively
participating
just
or
put
it
on
the
record.
It
might
be.
There's
conflicts
understood.
K
Two
two
things
briefly:
one
is
a
comment
on
lars's
comment,
which
is
the
given
the
difficulty
of
scheduling
this
meeting
along
with
everything
else
during
the
iatf
week,
in
addition
to
the
rs
a
b
problem,
there
are
ordinary
working
group
problems,
there's
a
working
group.
K
I
should
really
be
in
now,
and-
and
I
discovered
that
even
remotely-
I
can't
be
into
it
two
places
at
the
same
time,
and
that
might
be
a
very
strong
argument
for
holding
a
significant
fraction
of
these
meetings,
if
not
all
of
them
on
an
interim
basis
and
entirely
remote.
K
K
But
I
want
to
make
certain
that
we,
as,
as
was
said,
turn
these
things
into
tickets
and
and
address
them
on
the
on
the
list,
because
I
noticed
that
a
lot
of
comments
on
them
through
no
fault
of
the
people,
though
through
no
falter
back
or
other
summarizing,
just,
did
not
go
into
the
depth.
That
those
bullet
point
highlights
were
intended
to
to
raise
based
upon
office
conversations.
I've
had
with
brian
about
some
of
them.
A
No,
absolutely
and
one
of
the
chairs
first
duties
is
to
get
an
issue
tracker
set
up,
get
those
things
in
and
get
discussion
going.
As
I
said
earlier,
and
I
don't
know
if
you
were
present
for
it,
we
sort
of
view
before
there's
a
draft
about
the
topic.
We
we
will
moderate
any
discussion
that
goes
on
on
the
list
or
in
meetings
on
particular
topics.
A
Until
you
know,
such
momentum
has
occurred
that
we
get
someone
to
write
it
down
in
a
draft
and
ask
for
adoption,
and
then
it
will
become
a
work
item,
but
we'll
definitely
keep
those
loose
issues
that
aren't
attached
to
a
draft
in
part
of
the
issue
tracker
so
that
people
can
go
and
look
and
say
yeah.
Let's
get
on
this
and
write
a
draft.
A
K
And
exactly
right,
I
don't
know
if
others
have
had
the
problem,
but
it's
a
selling
personal
request
be
careful
if
that
issue
tracker
is
in
github,
because
github
is
wonderful
if
you
are
actively
following
a
particular
conversation
all
the
time,
looking
at
the
pull
requests
and
and
absorbing
things
that
way,
but
for
somebody
who
is
intermittently
tracking
a
particular
effort
or
trying
to
watch
that
effort
while
doing
a
lot
of
things,
it
can
be
so
confusing,
it's
becoming
just
has
to
become
useless.
D
The
proposal
we
floated
earlier
john
was
that
we'd
form
the
discussions
on
the
sorry
make
the
issues
on
github.
But
the
discussion
wouldn't
happen
in
a
list
and
we'd
simply
track
the
status
on
the
github
issues,
and
so
that
should,
I
believe,
capture
what
you're
hoping
for.
K
A
Sure
mark
nottingham
europe.
J
Is
that
working
yeah,
so
regarding
the
working
style,
I
I
understand
that
while
we're
getting
things
going,
synchronous
meetings
are
important
and
but
but
but
hopefully
I
I
would
really
like
to
see
the
group
resolving
most
of
its
issues
and
having
most
discussions
asynchronously.
I
think,
because,
frankly,
a
lot
of
people
here
are
pretty
time
poor
and,
as
we've
seen,
scheduling
is
difficult.
I'd
like
to
see
the
synchronous
meetings
reserved
eventually
for
just
you
know
resolving
those
issues
that
we've
identified.
That
really
need
that
kind
of
time.
J
So
that's
what
I'd
encourage
the
chairs
to
try
and
move
towards,
and
but
what
I
originally
got
in
the
queue
for
was
in
my
mind,
you
know
one
of
the
most
urgent
and
and
probably
practical
things
we
can
start
with,
is
figuring
out
how
to
continue
the
evolution
of
the
format
and
that
set
of
documents,
and-
and
you
know
I-
I
presume
that
this
group
has
the
authority
to
do
that.
J
The
question
is,
as
I
think
gecko
was
saying,
you
know
what
are
the
details
of
how
we
go
about
that,
and
so
I
guess
I
have
a
question
you
know
is:
is
it
really
the
expectation
that
we
need
a
draft
to
propose
how
we
adopt
those
drafts
and
process
them,
and
will
that
proto
draft
need
to
go
to
an
rfc
is?
Is
that
the
process
we've
set
up
here.
A
So
9280
does
specify
that
there
needs
to
be
a
draft
that
that
that
is
actually
a
requirement
of
9280..
It
does
not,
as
far
as
I
know,
need
to
be
an
rfc.
It
gets
passed
over
to
the
rsab
and
they
implement
it
as
a
policy
or
they
don't
or
they
they
more
to.
The
point
might
come
back
to
us
with
concerns
that
need
to
be
addressed,
but
as
far
as
I
know,
they
are
not
published
as
rfcs.
D
I
think
you
may
perhaps
be
talking
past
each
other,
so
I
think
if
mark
wanted,
to
propose
mark.
J
D
B
J
Okay,
is
anybody
working
on
such
a
draft
now.
D
No
so
mark,
I
think,
let
me
just
try
to
clarify,
so
I
think
maybe
you
and
peter
talking
past
each
other.
My
sense
is,
if
you
wanted
to
write
a
draft
that
was
about
about
evolving
the
format
and
like
you're,
like
the
format,
should
all
only
be
like
carved
and
stone
tablets.
You
could
do
that
right
now
and
you
wouldn't
need
a
protograph
to
do
that
draft.
D
So
I
think
that
I
think
that,
but
the
eventually
proposal
has
to
be
in
form
of
draft,
but
I
don't
think
we
need
a
draft
to
create
a
process
to
update
the
the
the
format
if
you
had
like.
I
think,
if
you
have
ideas
about
how
to
take
the
format,
I
think
you
can
provision
directly.
You
don't
need
a
draft
to
propose
how
to
propose
it.
J
Well,
I
I
so
I'd
like
to
see
you
know
this
group
start
working
on
the
evolution,
not
necessarily
as
I
I
think
that
we
need
to
think
about
how
we
go
about
that
and
what
the
right
process
for
it
is.
So
it
sounds
like
we
do,
maybe
need
a
draft
for
that.
D
Yeah,
well,
I
think
if
we
had,
I
guess
my
sense
is:
we
need
a
group
of
people
who
want
to
work
on
updating
the
format
and
enough
agreement
that
we
think
we
can
make
some
progress
on
that.
And
then,
if
there's
something
complicated,
that
isn't
just
we're
just
going
to
like
rev
the
rev
the
documents,
then
then
we
need
to
figure
out.
That
is
going
to
write.
D
D
Yeah,
I
think
the
question
the
question:
that's
also
resolved
that
was
sort
of
being
sort
of
bounced
around
earlier
is
exactly
like.
Should
this
group
own
the
entire
thing
soup,
the
nuts,
including
the
names,
the
tags,
or
should
it
not,
and
I
think
that
that
was
like
a
question
which
I
think
maybe
robert
and
I
and
like
I'm
happy
to
do
what
the
community
wants
to
do.
So,
I'm
not
here
to
like
enforce
anything
in
particular,
but,
like
I
felt
like
there
was
some
sense
from
like
mike
and
others.
D
J
Well,
just
just
to
to
that
point,
you
know
that
to
me,
the
names
of
the
tags
is
the
core
semantics
and
I
I
think,
that's
you
know,
that's
not
implementation.
Thank
you.
B
L
I
wanted
to
add
one
quick
comment,
which
is:
I
know.
John
levine
has
been
documenting
a
number
of
issues
that
he's
facing
and
it.
L
Good,
if
this
group
invited
him
to
discuss
those
so
that
when
we
make
sure
that
we're
capturing
everything
that
he's
seeing
at
the
operational
level
and
then
you
can
get
a
feel
for.
Oh
that's
policy,
that's
not
policy,
and-
and
you
know
you
get
a
little
running
code
in
the
process.
Thanks.
I
So,
with
respect
to
seven
nine
and
one
bis,
we
actually
discussed
a
little
bit
between
the
rs
app
or
the
stream
owners,
or
we're
gonna
call
this
and
the
ipc
and-
and
one
proposal
would
be
to
because
I
think
john
said
that
basically
we're
at
a
state
where
791
bus
actually
finally
describes
accurately
what
the
tooling
is
doing,
and
so
one
way
would
be
to
actually
publish
this,
as
is
as
a
record
and
then
start
to
work.
I
The
continuing
work
here
to
do,
because
otherwise
we
have
taken
a
document
that
has
sort
of
been
long
coming
and
and
we've
been
waiting
for,
and
we
potentially
delay
it
more
because
people
want
to
do
more
stuff.
So
I
I
personally
would
prefer
if
we
could
publish
this
relatively
quickly
and
then
do
the
work
here
to
do.
791,
bisbees.
I
To
this
group
right
because
it's
clearly
in
your
charter-
and
if
you
didn't
want
to
do
this,
you
you
couldn't
you,
you
can
choose
not
to
do
it,
but
I
would
recommend
we
do
it
that
way.
H
Kind
of
similar
about
what
I
wanted
to
say,
because
this
is
really
a
abyss
document
that
just
fixes
stuff
and
it's
a
biz
document
of
an
iab
stream
document,
and
I
think
that
the
faster
way
to
proceed
here
would
just
be
published
with
this
also
on
the
iab
stream.
And
then
you
start
over
new
with
a
clean
version.
Basically,
I'm
happy
to
like
have
a
short
discussion
or
kind
of
a
short
feedback
round
here.
H
I
think
it's
in
the
gray
zone,
so
the
the
seven
nine
and
one
what
yeah,
what
does
it
not
permit?
I.
D
H
H
But
this
is
a
that's
what
I'm
saying
so
this
is
an
ib
document.
This
is
a
biz
document
that
fixes
things.
So
it's
not
like
a
new
thing
right
and
it's
like
this
document
might
anyway,
anyway,
be
in
a
line
where
we
don't
know.
If
it's
policy
or
not
right,
it's
not
it's
like
it's,
not
clear
policy
or
something
like
that.
Well,.
H
A
H
A
I
I
agree,
I
don't
think
there's
a
difference
in
you
know
us
calling
the
consensus
or
the
iab
calling
the
consensus
at
this
point.
I
I
think
it
will
accomplish
that
in
the
same
amount
of
time
it
would
just
simply
be
a
bringing
to
this
group
make
sure
that
we're
agreed
that
the
community
is
okay
with
7991
bis
and
we
call
the
consensus
and
pass
it
over
to
the
rsab
to
approve.
J
Okay,
okay,
I
don't
think
it's
the
characterization
that
people
want
to
add
new
things
to.
It
is
not
really
relevant.
I'm
sure
that
somebody
out
there
somewhere
maybe
does,
but
that's
not
what's
top
of
mind
for
me.
J
It's
that
the
current
this
document
incorporates
a
lot
of
changes
to
79
91,
whatever
it
was
that
were
inserted
by
the
tooling
effectively,
and
that
may
be
the
right
thing
to
do.
J
But
those
changes
need
to
see
some
daylight
and
I
think
that
they
need
to
go
through
this
working
group
process
and
make
sure
that
we
understand
what
those
changes
are
that
they're
the
right
changes
to
make
and
then
we
can
publish
it
and
I
don't
think
that's
going
to
add
a
lot
of
time,
but
I
think
it's
the
right
thing
to
do.
I
I
don't
think
anyone's
proposing.
Oh,
let's
open
up,
7991
and
add
a
bunch
of
new
tags
and
do
a
bunch
of
new
stuff.
That's
that's
not
what's
really
on
the
table.
J
H
D
B
B
Assume
on
the
same
topic,
so
no
no!
This
is
apropos
this
particular
thing.
Yes,
I
agree,
there's
a
whole
bunch
of
changes,
many
of
which
I
don't
think
we're
a
good
idea
either
okay,
but
they
are
the
way
that
they
are
the
way
we've
been
publishing
rfcs
for
the
past
year,
so
in
particular,
if
you
say
this
change,
this
change
was
a
bad
idea
and
we
should
back
it
out.
B
We
can't
do
that
without
without
also
saying,
and
what
are
we
going
to
do
about
all
the
public
about
all
with
all
the
rfcs
that
use
it?
Are
we
good?
You
know?
I
think
I
mean
I
think
we
we
need
to
make
a
pass
over
the
xml
and
reissue
them
with
cleaning
up
the
xml,
but
my
guess
is
that's
going
to
take
more
than
more
than
a
few
days
of
discussion.
A
Understood
robert
you're
in
the
cube.
G
Even
if
we
disagree
that
what's
been
built
is
what
we
should
be
doing.
I
think
that
having
that
captured
so
that
we
can
document,
the
rfcs
that
have
been
published
to
date
is
going
to
be
important.
While
we
are
going
through
the
fight
about
whether
or
not
we
actually
revise
rfcs,
you
know
to
republish
that's
going
to
be
a
long
fight,
so
I
would
like
to
actually
have
an
rfc
artifact.
G
That
says
this
is
what
the
tooling
is
currently
doing,
even
if
it's
full
of
commentary
that
says
we
don't
think
he
should
do
that
anymore
and
then
do
the
step
that
says
this
is
what
we
should
change.
E
E
E
E
Going
back
to
what
maria
said,
it
would
be
good
for
us
to
publish
a
document
that
says
what
are
we
doing
today
and
actually
backtrack
it
to,
and
we
started
doing
these
things
on
this
date,
but
it's
not
fodder
for
starting
79.91
bits.
Some
of
the
stuff
will
go
in
some
of
it.
Won't
there
will
be
a
consensus
process,
but
let's
conceptually
really
split
that
out
between
a
document
that
says
starting
on
this
date.
Xml
rfcs
started
looking
like
this
and
what
do
we
want
later
completely
different
work.
A
And
a
big
thumbs
up
from
mike
in
the
corner,
elliott,
you're
up
hi.
L
A
question
and
a
comment:
I'll
go
with
the
comment.
First,
my
question
will
be
for
paul.
Just
so
you
know
paul.
L
My
comment
is
that
it
seems
like
what
we
have
here
is
a
great
great
opportunity
to
sort
of
exercise
the
process
a
little
bit
and
hopefully
on
something
that
isn't
quite.
I
was
going
to
say
too
controversial,
but
now
I'm
not
so
sure,
but
I
actually
look
forward
to
seeing
that.
I
think
it's
a
good
thing
for
the
work
to
happen
here
and
not
the
iab
for
exactly
this
reason
that
we
should
learn
how
to
use
our
processes
to
do
these
update
these
updates.
L
Unless
there's
something
that's
absolutely
critical.
That
has
to
happen
yesterday
and
then
I'm
not
even
sure,
then
the
iab
should
deal
with
it.
My
co,
my
question
to
paul
was,
if
you
don't
view
this,
the
document
is
abyss
document.
Is
it
setting
a
standard?
I
don't
mean
in
the
ietf
sense,
but
I
mean
in
terms
of
the
specification
sense:
is
it
setting
a
a
set
of
rules
by
which
the
the
documents
are
published
or
is
it
doc?
L
What
is
it
documenting
because
I
sort
of
lost
you
there
a
little
bit
about
what
it
is
you
wanted
thanks
for
for
clarifying.
E
E
It
is
not
a
standard
and
it
was
certainly
not
agreed
to
in
the
way
that
the
original
spec
was
agreed
to,
which
was
it
was
an
iab
document.
It
had
a
lively
ietf
last
call
changes
were
you
know
like
like
it.
The
original
document
was
that
way.
This
is
not
documenting
something
that
went
through
that
process.
It's
an
implementation
so.
A
A
We
are
publishing
this
document
for
the
purpose
of
documenting
that
for
people
who
are
using
it
and
in
the
future
we
are
going
to
likely
set
new
policy
which
creates
you
know
what
we're
going
to
do
in
the
future.
But
this
documents
it
for
purposes
of
use
only
is
that
a
comfortable
thing
to
do
for
this
group.
I
The
last
segment
yes,
so
this
is
actually
what
I
was
going
to
say
coming
to
the
microphone.
You
said
it
for
me,
so
I
don't.
I
think
all
of
this
is
fine,
so
I
I
personally
would
like
a
document
that
that
describes
what
the
current
tools
are
doing.
I
think
that's
also
what
robert's
concern
is
that
we
we
have
sort
of
a
description
of
of
what
we
are
have
now,
whether
that's
what
we
want
or
not
is
is
up
to
debate,
and
I
am
hearing
it's
not
that's
fine
right.
I
I
don't
really
have
not
religious
views
here,
but
I
we've
operated
for
too
long
in
a
situation
where
the
description
of
what
should
be
done
and
what
action
was
done
were
different
and
it
confused
a
lot
of
things
and
if
we
have
a
chance
to
sort
of
align
that
and
then
move
on
from
it
pretty
much
immediately
that
that's
completely
fine,
whether
it's
1791
biz
or
not,
I
actually
don't
care
right.
It
could
be
an
individual
document
that
says
here's
a
description
of
the
tool
and
we
leave
it
at
that.
I
A
I
guess
my
take
with
chair
hat
on.
Is
it's
not
necessarily
setting
policy?
It
is
purely
descriptive
of
the
tool,
so
it
need
not
be
on
the
rswg,
but
if
the
street,
if
the
rsab
thinks
that
it's
okay
to
put
that
kind
of
policy
in
the
editorial
stream,
I
don't
think
I
have.
I
don't
have
a
problem
taking
it
on.
As
a
working
group
item
miria,
you
want
to
comment
on
this
or
other
pieces
of
it.
H
So
this
is
just
not
as
ib
chair
or
offset
member
or
whatever
you
know
this
work.
The
biz
document
is
already
done.
It's
really
just
like
reflecting
what's
implemented,
it
needs
to
be
published,
and
I
think
it's
a
waste
of
time
for
this
group
we
should
and
like
because
elliot
says
this
might
be
a
good
thing
to
like
test
our
process,
but
it's
not
because
it's
done,
we
need
just
to
publish
it.
We
should
take
on
more
important
issues
on
this
group.
D
I
got
down
here
because
I
wasn't
sure
there's
a
chair
comment
or
personal
comment,
so
it
seems
to
me
this
document
has
two:
despite
having
one
set
of
text
has
two
meanings.
D
One
set
of
meetings
is
this:
is
the
behavior
of
this
tool
on
the
structure
of
the
documents
up
until
the
moment
this
document's
published,
and
that
is
a
documentation
function
and
the
second
is
and
going
forward.
If
you
wish
to
have
your
things
published,
it
must
conform
to
the
syntax
until
it
changes,
and
that
is
that
is
a
policy
and
specification
function.
And
now
we've
been
operating
in
this
like
law
free
zone
where
the
tool
just
dictated
these
policy
decisions
and
like
when
it
never
had
consensus
but
like
we
have
to.
D
But
but
the
point
of
the
exercise
is
to
get
to
the
point
where
that's
no
longer
the
case
and
where
those
policies
decisions
come
from
somewhere
and
so
people
which,
like
cease
publishing
rfcs
from
the
moment
this
doc
has
published
until
our
business
is
published,
then
that's
like
totally
criminal
and
that
document
can
go
anywhere,
including
on
a
website.
But
if
people
wish
to
be
out
of
the
law
free
zone
and
have
a
document
which
has
text
which
enforces
text
about
how
things
have
supposed
to
behave,
then
that
has
to
come
from
here.
D
J
No
there
it
is
working,
so
people
are
talking
about
this
document
as
as
it's
documenting,
what
a
tool
does
the
problem
is
is
that
there
are
more
than
one
tool
now
touching
this
format,
and
I
find
it
really
confusing
and
concerning
that
the
ietf
which
is
supposed
to
be,
you
know
this
body
of
knowledge
and
people
who
understand
how
interoperability
works,
are
basing
something
on
one
implementation
and
not
on
documenting
an
interoperable
format
that
people
can
write
tools
to.
I
don't
think
this
document
is
done.
J
I
think
it
needs
people
to
at
least
understand.
You
know
what
decisions
have
been
made
and
we
need
to
make
sure
that
we
make
some
practical
decisions
about
what
it
contains.
It
may
be
that
there
are
some
things
that
aren't
optimal,
that
we
still
leave
in,
but
we
can't
just
wave
our
hands
and
say:
oh,
that's,
not
our
problem.
That
doesn't
make
any
sense
to
me
at
all.
M
Okay-
sorry,
sorry
for
that,
hopefully
this
works.
I
don't
have
a
headset
here.
I
didn't
expect
that
I
wanted
to
say
something.
I
wanted
to
point
out
two
things.
What
we
are
going
to
do
here
is
essentially
exactly
what
was
planned
quickly
after
791
was
published,
because
that
was
published
with
the
understanding
that
this
is
a
snapshot
that
would
be
quickly
revised
based
on
implementation
feedback
and
how
long
is
that
ago,
seven
years,
eight
years,
so
what
we
are
doing
now,
hopefully,
is
starting
that
work
properly.
M
We
are
doing
that.
The
other
thing
I
mentioned
on
the
chat.
There
are
different
kinds
of
flaws
in
the
biz
document
and
actually
in
the
791
as
well
and
some
of
them.
M
A
So
we
are
now
out
of
time
and
have
five
people
left
in
the
queue
we
can
creep
over
a
couple
of
minutes
until
we
are
chased
out
but
paul.
If
you
would
like
to
make
a
quick
comment,
I.
E
H
So
poor,
yes,
it
should
be,
but
it
will
not
be
quick
right.
So
that's
why
I
would
like
to
publish
this
and
then
start
a
new
document
and
and
the
reason
why
I
want
to
publish
this
is
I
want
to
use
mark's
argument
against
him.
It's
interoperability
right.
H
Other
implementations
should
be
able
to
actually
implement
what
we
need,
and
so
we
need
to
document
it
and
that's
a
reason
and
like
what
I'm
hearing
is
that
I
don't
like
this
group
needs
consensus
to
publish
something
we
will
not
reach
this
consensus,
so
I
don't
think
publishing
this
document
as
it
is
in
this
group
is
actually
an
option,
but
I
still
think
we
should
publish
it.
I
Lars
yeah
looks
like
I
agree
with
maria
that
I
think
we
should
publish
this
as
a
record
of
where
we
are
and-
and
I
also
I'm
fine
with
if
the
rswg
wants
to
publish
this
document
on
the
editorial
stream,
because
I
mean
we're
not
starting
from
a
clean
slate
like
far
from
it
right.
We
have
a
little
history
here
and
it's
complicated
and
I
think
we
can.
I
If
you
know,
if
you
hold
our
nose-
and
we
say
you
know,
this
is
not
perfect,
but
it's
what
the
current
tooling
requires
to
get
internet
drafts
and
rfc
is
published
and
it'll
change
in
the
future.
But
here's
what
it
currently
is.
I
think
there's
value
in
that,
and
you
know
I
agree
with
mark
right.
It's
it's.
It
hasn't
seen
consensus
or
not
enough
and
and
it's
really
sort
of
based
on
what
one
implementer
did,
but
it
is
what
it
is
and
and
basically
pretending
it
isn't,
is
not
going
to
help
anybody.
A
K
I
I
thought
mary
and
I
were
in
complete
agreement
until
her
last
sentence
and
now
I'm
not
sure
anymore
partially,
because
I
agree
with
mark.
I
think
it's
important
to
get
a
snapshot
of
this
thing
published
and
publish
it
soon,
but
make
clear
that
that
snapshot
is
a
snapshot
of
an
implementation.
K
That's
not
normative,
there's
no
expectation
that
other
implementations
should
run
off
and
conform
to
it
until
it's
an
opportunity
to
discuss
the
issues
of
contention.
I
think
a
snapshot
helps
us
figure
out
where
those
issues,
content
and
contention
are
that's
a
good
idea,
but
I
think
we
need
to
be
very,
very
clear
about
what
we're
doing
here.
Thank
you.
A
So
I'm
hearing
that
what
we're
gonna
do
is
hopefully
paul
has
some
good
notes
on
this
and
post
them
to
the
list.
We
will
watch
the
list
for
a
little
while
see
if
people
have
additional
comments
that
change
what
has
been
said
in
the
room
and
then
ecker,
and
I
will
put
our
heads
together
and
see
what
we've
heard
and
come
out
with
some
sort
of
call
on
this
all
right
with
that.
We
are
three
minutes
over
and
much
appreciated,
and
I'm
surprised
we
actually
got
some
substantive
discussion
done.
So
that's
nice.