►
From YouTube: IETF114 AUTH48GITHUB 20220726 1200
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).
B
Well,
I
want
to
thank
people
for
coming.
I
give
people
a
couple
of
minutes
to
get
settled
and
then
we
can
get
started.
B
All
right,
so,
please,
let
me
know
if
you
can't
hear
me,
I
will
let
you
know
if
I
need
you
to
speak
up,
so
welcome
to
this
session
to
discuss
using
github
or
some
technology
for
doing
collaborative
authoring
or
diffs
or
issue
tracking
during
auth
48.
B
I've
set
up
the
the
agenda,
so
people
could
provide
comments
and
suggestions
for
topics
to
talk
about.
So
let
me
move
through
the
slides
here.
B
I've
included
the
note
well
because
this
is
a
site
meeting
of
the
ietf.
This
talks
about
how
you
purchase
how
we
participate
in
these
sessions.
Okay,
you
should
have
seen
this
already.
B
All
right,
so
the
agenda
covered
the
note.
Well
I'd
like
to
do
some
agenda
bashing,
so
the
overview
of
the
the
topics
that
we
wanted
to
go
over.
Some:
a
brief
description
of
our
editing
process,
previous
experiments
that
the
rpc
has
run
and
then
the
ideas
that
were
put
on
the
agenda.
B
So
we've
got.
B
Oh,
I
see
somebody's
joined
the
queue
martin.
A
B
Yes,
that
is
the
what
benefits
and
features
are
we
seeking
is
both
authors
and
editors
and
then
talking
about
the
technology
and
we've
said
github:
do
we
really
need
github
talking
about
where
the
source
files
live,
who's
controlling
them?
Can
the
processes
that
we
are
discussing
be
offered
to
all
authors
during
all
48
and
then
more
into
the
details?
What
would
pull
requests
and
diffs
look
like
so
my
own
agenda
bash
is
that
we
skip
going
over
the
previous
experiments.
B
B
B
So,
just
briefly
just
want
to
say
that
we
are
talking
about
auth
48
and
the
use
of
github
for
the
edit
state.
The
rfc
editor
state
we're
not
going
to
cover
the
edit
state.
We
do
all
sorts
of
stuff,
we
start
with,
you
know
could
be
just
text
files
or
v2
or
v3,
and
we
we
make
changes
to
those
we
move
them
to
v3
and
through
multiple
passes.
B
We
make
various
edits
everything
from
adjusting
commas.
To
asking
questions
about
passage
clarity,
then
you
know
the
rfc
editor
state,
that's
a
pass
by
another
editor
and
and
when
we
are
done
with
the
documents
we
present
them
during
all
48.
So
we
have
our
xml
file
with
the
questions
in
them
and
the
files
that
we
present.
So
you
can
see
the
changes
that
we've
made.
So
what
we're
focusing
on
is
how
authors
would
want
to
use
github
and
perhaps
an
experiment
for
auth48.
B
We've
done
this
a
few
times
already.
So
here
are
the
previous
experiments
and
if
you
follow
the
link,
there's
a
lot
more
information,
and
it
also
includes
the
feedback
from
the
authors
and
the
editors
when
we
got
it.
One
of
the
the
documents
the
authors
did
not
respond
to
the
survey,
but
if
we
have
time
we
can
come
back
to
these
slides.
B
B
So
are
we
talking
tracking
content
changes
the
distributed
authoring
issue,
tracking
pull
requests?
Audit
trails?
What
do
we
want.
D
Mike
fisher,
I
I
think
the
answer
here
is
kind
of
yes
and
we
do
want
the
audit
trail
of
what
changes
were
made.
We
want.
We
want
to
be
able,
when
there's
a
this
document,
to
be
able
to
pull
in,
like
start
from
where
we
were
already
have
it
ready
to
go.
D
We
when
we
worked
on
the
quick
documents,
a
big
part
of
it,
was
that
changes
were
sent
out
to
the
working
group
of
if
you,
if
you're
interested.
This
is
what's
happening.
B
A
Yeah,
so
I'm
going
to
slightly
disagree,
maybe
and
maybe
add
to
what
what
mike
just
said.
The
the
thing
that
I
was
I've
been
looking
for
from
this
process
is
really
the
ability
to
review
the
changes
as
they
come
in.
A
That's
that's,
basically
it,
and
that
has
been
rather
difficult
because
they
tend
to
tend
to
arrive
all
this
one,
one
giant
blob,
an
undifferentiated
mass
where
you
have
xml
changes,
you
have
minor
grammar,
grammar
and
so
forth,
editing
so
commas
and
which,
and
that
and
all
those
sorts
of
other
things
piled
in
there,
as
well
as
some
of
the
more
substantive
stuff.
Where
there's
a
sentence,
that's
unclear
and
the
there's
an
edit
being
made
to
to
improve
the
clarity,
plus
all
of
the
issues
that
are
raised
in
in
the
process.
A
So,
to
give
an
example,
when
we,
when
we
did
quick,
we
essentially
had
to
go
through
the
entire
document.
Looking
for
each
one
of
these
things
as
we
went
down
so
the
the
first
thing
that
we
did
was
looked
at
the
I
think
the
text
output,
because
you
can
get
a
nice
clean
diff
and
you
look
for
the
the
textual
changes
and
you
go
through
all
of
that.
And
then
you
sort
out
the
differences
there
and
you
merge
in
all
of
those
changes
that
that
are
good.
E
There
so,
first
of
all,
I
agree
with
what
was
just
said:
we've
been
through
all
copyright
for
the
http
docs
last
month,
and
so
I
some
of
them
were
marked
up
in
cram
down
some
in
native
xml,
the
main
issue
that
I
see
and
I'm
just
rephrasing
what
martin
essentially
said
for
our
specs.
We
actually
want
to
have
a
track
record
about
what
changed
when
and
why
and
have
that
complete.
E
So
when
we
started
on
the
revision
of
the
http
specs,
we
could
actually
start
from
a
source
code
repository
that
had
the
whole
history
of
the
specs
since
15
years
ago,
or
something
something
like
that
and
now
in
the
edit,
an
auth
48
phrase.
Unless
we
backport
every
single
change,
we
lose
that
information
and
backporting.
These
changes
means
that
we
have
to
look
at
each
change
and
see
whether
it's
just
a
typo
fix
an
editorial
improvement.
E
Some
bigger
change
that
came
up
during
oauth
48,
which
requires
a
working
group
discussion
potentially
so,
as
martin
said.
Most
of
that
apparently
is
during
edit,
not
during
earth
48.
E
So
I
think
that's
really
what
what
we
need
to
look
at
and
I
don't.
I
don't
think
we
should
look
at
the
actual
technology
for
that
right
now,
maybe
at
the
end,
but
we
should
try
to
understand
why
people,
how
much
transparency
we
need.
I
mean
if
it's
some
kind
of
public
repository,
that's
good,
whether
it's
github
or
something
else
is
a
different
discussion.
F
Yeah
I
mean
I
would
largely
agree
what
martin
said
is
like
critically
important
to
be
able
to
distinguish
every
single
change.
That's
been
made
and
figure
out
why
it's
been
made
and
not
have
to,
like.
You
know,
wade
through
like
a
bunch
of
changes
which
are
fundamentally
not
don't
change
the
text,
but
only
change
formatting
and
look
at
the
changes
to
make
formatting
and
have
this
separated
out.
F
The
other
thing
that's
important
is
to
actually
allow
the
authors
and
the
ads
and
the
rpc
to
collaborate
during
the
final
phase
of
this
as
changes
that
as
the
final
read-through
happens,
and
you
notice
changes
and
they
have
to
be
tracked
and
they
have
to
be
managed
the
process
and
having
those
in
emails
is
like
very
difficult
and
finally
being
able
to
understand
what
the
state
of
the
document
is
at
any
given.
F
Time
is
also
critical,
so
you
know
to
get
a
repository
like
yet
always
has
the
current
state
in
invest
in
maine,
but
you
know,
for
instance,
administration,
where
you
know
you,
don't
you
download
the
xml
file
from
the
from
the
from
the
site,
it's
the
same
url
every
time.
G
My
my
view
is,
I
mean
I
don't
want
to
contradict
anyone
else.
Actually
I
agree
with
them
very
much,
but
specifically,
the
thing
that
I
see
is
that
we
get
inconsistent
amount
of
engagement
from
authors.
They
don't
know
where
it's
going
on
or
whether
they're
reviewing
the
current
state
and
I
think
that's
what
eckerd's
kind
of
getting
at
the.
We
need
the
latest
thing
and
they
need
to
be
looking
at
what's
going
on
and
so
to
to
a
certain
extent.
G
I
think
that
that
it's
actually
it's
actually
issue
tracking
and
the
ability
to
have
an
author
say
quite
easily.
Yes,
I
agree
with
this.
Yes,
I
agree
with
this.
This
is
the
part
I
have
a
problem
with,
and
I
think
that,
particularly
with
the
big
long
diffs
and
the
emails,
some
of
us
are
really
good
at
going
through
them,
and
some
authors
are
really
not.
They.
G
D
Yeah,
so
back
up
again,
nothing
has
been
said
that
I
disagree
with,
I
think,
to
expand
on
a
couple
of
those
julian
mentioned
in
passing.
One
thing
that
I
think
makes
this
a
little
more
complicated,
which
is
that
not
all
of
us,
author,
an
xml,
and
so
you
know
I
was
working
in
markdown.
D
D
But
the
other
thing
I
wanted
to
highlight.
Ecker
was
mentioning
ad
reviews.
I
did
find
it
very
helpful
during
off
48
for
http
3.,
when
the
email
went
to
the
ads
of
here
are
substantive
changes
that
were
made
in
all
48
80s.
Do
you
approve
it
and
then
I
was
immediately
able
to
follow
up
with
and
here's
the
issue
discussion.
Here's
the
pr
where
this
happened.
E
B
H
So
I
wanted
to
point
to
some
corners
in
some
of
the
statements
that
julian
and
mike
have
made
and
asked
for
thinking
about
the
implications
julian
in
particular,
talked
about
the
working
group
having
the
history
going
back
years
for
a
document
and
wanting
to
maintain
that.
And
there
is
an
implied.
H
All
of
that
time
at
least
heard
strong
complaints
about
having
to
go
in
and
and
copy
things
back
into,
the
format
that
the
working
group
had
been
using
and
as
we're
working
our
way
through
this
problem
think
about
what
would
happen
if,
for
instance,
one
of
the
things
that
that
jay's
been
poking
at
if
we
actually
explicitly
created
a
different
authoring,
grammar
and
publication
grammar,
whether
you
know
what
impact
that
would
have
on
attempting
to
have.
I
Yeah
I
just
wanna
a
couple
of
people
have
touched
on
it,
but
just
to
make
it
really
explicit
about
a
third
of
all
drafts
submitted
in
the
past
year
were
written
in
some
form
of
markdown,
and
I
understand
that
you
want
to
work.
The
rpc
needs
to
work
with
the
publication
format,
but
it's
difficult
mike
has
talked
and
go
about
how
he
had
to
go
back
and
forth.
I
had
the
same
thing
with
my
little
10
page
draft.
I
I
I
B
J
Unmuting
is
really
slow
on
this
that
one
sorry,
I
should
have
done
that
before.
J
I'm
really
trying
to
focus
here
on
the
authoring
process
as
a
whole
and
auth
48
is
is
an
important
period
in
that
authoring
process.
It's
preceded
by
working
group
work,
author
work
and
so
on.
It's
followed
by
working
group
work
and
author
work
in
many
many
cases,
because
there
are
this
documents
and,
of
course
in
in
that
miss
work,
as
other
people
have
said
it,
it's
really
useful
to
be
able
to
see
who
did
what?
J
Why
so
right
now
we
we
get
the
the
finished
xml
files,
the
the
non-prepped
ones,
those
that
are
still
in
the
authoring
version
of
rfc
xml
and
not
not
the
publication
version,
and
we
run
those
through
an
upconverter
and
and
get
back
marked
down.
But
that,
of
course,
has
a
lot
of
formatting
done
different.
That
has
become
better
with
the
rpc
no
longer
reformatting
things
I
have
heard.
J
I
haven't
actually
been
part
of
a
process
where,
where
that
was
important
yet,
but
what
I
really
would
like
to
focus
on
is
the
the
authoring
processes.
The
long
process
of
48
is
a
period
somewhere
in
that
process
and
the
better
it
actually
integrates
with
the
the
other
parts.
Before
and
after
that,
the
easier
it
is
to
create
quality
documents.
B
I
I
did
want
to
follow
up
on
your
comment
that
the
rpc
is
not
formatting
in
in
what
way,
because
we
we
do.
Actually
our
formatting
steps
are
at
the
very
beginning.
We
we
get
the
a
a
document,
it
could
be
a
v,
two
could
be.
Text
could
be
v
three,
but
our
formatting
pass
is
at
the
beginning,
and
and
that's
when
we're
looking
at
lists
and
tables
and
artwork
and
source
code
and
getting
it
all
up
to
a
certain
level
of
v3.
J
K
K
A
draft
goes
into
the
rfc
editor.
It
is
not
seen
again
until
it
is
edited
and
formatted
and
whatever,
and
then
there
is
a
list
of
there's.
The
question
is
this
good?
Given
that
we're
talking
about
tools
and
tools,
don't
have
to
be
a
single
step.
K
A
different
proposal
would
be
that
in
fact,
we
get
rid
of
the
concept
of
off
48.
We
keep
the
concept
of
final
sign
off,
but
in
fact,
if
something
comes
in
as
a
text
file
or
as
markdown
that
the
rpc
first
does
an
editing
pass,
not
a
formatting
pass,
they
do
the
you
know,
and-
and
that
comes
out
at
least
in
my
experience
in
auth48,
ignoring
formatting
editing
comes
out
in
approximately
two
buckets
editorial
and
questions
editorial.
K
I
actually
look
through
because
I'm
sort
of
picking
on
that's
in
witches,
sorry
about
that,
I'm
not
as
bad
as
some
of
your
other
authors.
Who
will
disagree
with
you
on
those,
but
I
do
check
on
those
if,
in
fact,
the
process
is
an
editorial
process
followed
by
a
formatting
process
and
and
then
of
course,
the
authors
have
to
to
do
a
second
sign
off
and
the
editorial
process
is
done
on
the
input
format.
K
It
would
make
it
it
would
get
you
better
answers
to.
Is
this
right?
How
does
this
look?
Those
won't
get
lost
as
easily,
and
it
also
means,
quite
frankly,
I
think,
for
the
formatting
passer
was
it's
going
to
go
yeah
yeah
right,
whatever
you
know
like
that,
they
actually
don't
care
about
that.
You
know
like
the
worst
thing
you
could
do
is
make
their
lists
wrong,
and
you
know
that
even
that
I
would
suspect,
is
extremely
rare.
K
K
When
there's
multiple
authors,
sometimes
the
authors
disagree
and
I've
had,
I
don't
remember
what
it
was,
but
sometime
in
the
last
two
years
I
was
in
a
situation
where,
because
I'm
fast,
I
said
yes
to
things
and
one
of
my
co-authors
said
no,
and
I
don't
know
how
that
might
have
messed
you
all
up.
You
might
have
started
taking
paul's
yeses
and
you
know
going
ahead
and
then
had
to
backtrack,
but
the
email
from
that
got
messy
very
quickly
and
basically,
my
co-author
just
gave
up
because
I
had
jumped
in
too
quickly.
K
Yes,
yes,
yes,
and
if
the
other
authors
want
that's
fine,
but
this
goes
back
to
especially
what
martin
was
asking
for
was
tracking
in
the
process,
because
just
because
I
said
yes
and
now
the
text
looks
like
this
doesn't
mean
that
that's
what
my
co-author
wants
and
in
particular
doesn't
mean
what
my
ad
wants
and
then
again
just
do
the
formatting
at
the
end.
I
know
the
formatting's
not
trivial,
but
for
us
authors,
the
outcome
of
the
formatting
is
trivial,
we're
just
going
to
say.
K
B
Yeah,
thank
you
and
just
to
comment
on
how
we
process
author
answers.
Yes,
we
assume
that
the
author
speaking
is
already
checked
with
their
co-authors
and
we
go
forward
with
the
feedback
we
receive.
If
an
author
comes
back
later
and
says
they.
G
K
Not
co-author
on
that
I've
watched,
I
believe
that
that
is
basically
never
true
and.
D
E
Actually,
sometimes
this
is
even
not
true
for
a
single
author,
because,
like
me
in
past
48,
I
had
forgotten
that
I
had
agreed
to
something
weeks
before
I
wanted
to
say
something
about
what
you
just
said
earlier
about
format:
conversion,
which
is
very
important
for
you
and
for
the
whole
process.
But
I
think
most
of
the
people
sitting
here
are
already
submitting
these
three
documents
either
because
they
edit
them
or
because
krembo
generates
them
for
them.
E
So
that
might
explain
why
lots
of
the
feedback
that
you
get
isn't
concerned
about
that
step.
So
that's
just
an
explanation,
because
those
people
submitting
plain
text
or
v2
documents
probably
are
not
here
in
this
meeting.
C
E
The
other
thing
I
wanted
to
comment
on
was
robert,
who
I
think
asked
whether
I
actually
wanted
the
edits
of
the
rpc
to
be
done
in
my
source
control
system.
In
my
native
repository
and
of
course,
the
answer
to
this
is
in
a
perfect
world.
Yes,
if
that
would
be
possible,
but
we
have
a
large
spectrum
between
what
the
author
has
used
for
editing
and
tracking
and
what
we
currently
use
emails
about.
48.
E
And
we
don't
need
to
go
from
zero
percent
to
what
one.
L
G
G
B
Thank
you,
ecker.
F
Yeah
I
mean
I,
I
was
actually
gotten
cute
to
say
much.
What
paul
said
you
know.
Just
I
mean
operationally
like.
I
find.
F
The
two
biggest
challenges
in
this
process
are
one
back
parting,
all
the
material
to
mark
down,
because,
like
I
want
when
I
want
to
prepare
abyss,
I
want
to
have
the
markdown
look
like
the
you
know,
produce
roughly
the
same
text
as
previously
the
case,
so
I
don't
think
we
do
it
again
and
that's
like
enormous
challenge
and
then
finding
and,
as
I
say,
disentangling
all
the
different
changes
you
know
in
a
traditional
document,
preparation
process,
you
would
have
a
proofreading
you're.
F
Sorry,
I
have
a
copy
editing
phase,
which
is
done
entirely
on
this
on
the
on
the
source
text
with
no
type
setting
at
all,
and
you
have
proofreading
phasers
down
on
the
on
the
type
setting
on
the
typeset
manuscript.
You
know
on
the
galley
proofs,
and
so
we
don't
have
that
we
have
one
phase
and
and
like
really,
we
need
to
separate
those
in
order
to
like
actually
have
things
work
out
properly.
I
understand
there's
a
certain
reluctance
to
work
in
like
multiple
circumstant
formats.
F
You
know
my
sense
is
that
we
could
tolerate
more
than
one,
but
probably
not
infinite.
So
you
know,
I
think
my
put
would
be
like
obviously
smlv3
anything
else
which
has
like
a
really
large
user
base.
Where
I
think
cram
down
is
at
this
point,
and
then
you
know,
if
we're
gonna
do
a
copy
edit
phase
and
people
insist
on
using
something
that
was
not
one
of
those
things.
F
The
copy
edit
can
happen
simply
by
marking
up
the
actual
text
files
as
opposed
to
marking
up
the
source
format,
and
then
people
can
backport
them
into
their
own
stuff
and
you
can
proofread
it
out,
but
I
think,
like
the
I
mean,
I
guess
one
thing
I
would
say
is
that,
like
in
a
traditional
document,
preparation
format,
the
author
is
responsible
for
making
the
copy
edited
changes.
The
copy
is
responsible
for
making
the
copy
edit
and
telling
the
officers
about
them,
and
we've
inverted.
F
That
process,
which
puts
like
a
lot
of
burden
on
the
authors
to
like
dope
out
what
the
changes
were
and
tools
can
make
that
easier.
But
like
you
know
that
that's
probably
that's
part
of
the
source
of
the
problem
here.
H
Yeah,
I'm
going
to
go
risk
going
slightly
out
of
scope
I'll
keep.
It
short
I'd
like
to
ask
people
to
think
about
a
future
that
looks
quite
a
bit
different
than
the
one
that
we
are
currently
making
consider
talking
about,
making
small
changes
to
and
making
a
big
change
to
the
way
that
we
process
our
documents
and
I'm
all
speak
in
terms
of
implementation.
B
D
D
We
made
the
changes
in
markdown,
we
produced
a
new
output
xml
and
sent
that
back
to
the
rfc
editor,
and
then
you
had
to
do
all
your
formatting
over
again
and
I'm
very
sorry
about
that.
But
effectively.
It
means
that
the
formatting
happened
at
the
end
anyway,
like
paul
is
suggesting-
and
you
also
discovered
something
that
was
in
the
document
that
I
didn't
even
realize-
the
markdown
could
not
produce
and
you
fix
it
for
me
and
it's
still
and
it's
still
not
right
in
the
repo,
because
I
can't
get
the
mark
down
to
do
that.
B
Sounds
like
something
an
issue
to
open
up
on
markdown.
D
L
L
I
think
it's
important
to
remember
that
the
rpc
is
a
professional
publishing
function,
that's
a
well-established
thing
that
we
have,
and
that
means
that
at
some
point,
change
control
of
the
document
will
move
from
the
authors
to
the
professional
publishing
function
and
we've
decided
that
that's
auth
48,
and
that
means
then
that
at
that
point,
as
well
as
them
having
change
control
it's
their
processes
that
they
do
that
they
think
fit
best
with
them
for
them
to
be
able
to
manage
it.
L
So
on
that
basis,
I
think
we
need
to
separate
out
two
second
thing:
two
separate
things
here.
The
first
is
the
requirement
for
being
able
to
track
and
categorize
and
understand
the
individual
changes
made
by
the
rpc.
L
I
think
that's
a
straightforward
requirement,
but
we
need
to
remember
how
the
editors
work
as
gene
explained,
they
work
as
human
beings.
They
don't
go
through
and
do
right
I'll
do
one
pass
for
this,
then
one
pass
for
that.
Then
one
pass
for
that.
Then
one
pass
for
that
they
go
through
the
document
and
whatever
stands
out
for
the
document
is
what
they
they
tackle.
L
B
L
Change
tracking
is
actually
quite
separate
from
the
other
thing
that
a
number
of
people
have
raised
here,
which
is
tying
that
those
changes
back
to
the
original
source
format
and
authoring
process.
That
is
actually
a
significantly
harder
problem.
I
understand
the
this
issue,
but
I'm
not
convinced
that
trying
to
fix
that
for
every
id
up
front
is
necessarily
the
best
way
forward
and
again,
I
think
that
we
should
perhaps
consider
some
technical
solutions
for
dealing
with
this
particular
issue.
L
If,
for
example,
we
had
perfect
bi-directional
translation
between
markdown
and
xml,
then
that
would
resolve
a
lot
of
things.
So
I'd
just
like
us
to
try
to
separate
those
things
out
a
little
bit
and
see
if
we
can,
you
know,
apply
some
technical
skills
in
order
to
fix
these
things.
M
So
I
I
wanted
to
it's
actually,
oddly,
this
sort
of
speaks
to
some
of
jay's
points.
Here
I
mean
I,
I
often
hear
sort
of
arguments
of
like
well.
M
If
there's
this
this
professional
group,
that
does
things
a
certain
way
it
doesn't,
and
it
is
a
very
professional
group
right,
but
because
it
is
a
group
that
we
contract
and
do
contract
with,
and
it
is
a
professional
group
that
does
that
full
times
I
mean
you
know
we
teach
most
new
authors
to
use
xml
or
markdown
or
one
of
those
things
in
a
matter
of
a
couple
of
hours.
Github
is
another
couple
hours
like.
I
definitely
think
that
we
should
take
as
part
of
the
solution
space
for
this
we
should
not
re.
You
know.
M
Obviously
the
rfc
editor
could
learn
how
to
do
documents
in
any
one
of
these
things
in
a
completely
trivial
amount
of
time
compared
to
the
overall
time
we
pay
them
for
every
year.
So
I
do
think
that
we
need
to
figure
out
a
tool,
path
and
tool
chain
that
that
works
on
this.
I
do.
I
agree
very
much
with
the
the
the
separation
of
the
the
two.
M
You
know,
ideas
that
people
talk
about
here,
one
of
being
understanding
the
changes
and
why
they
were
made
and
a
different
one
of
the
back
porting
type
issues,
but
it
doesn't
really
seem
that
difficult
to
solve
both
of
those
and
not
in
in
every
way
possible.
But
you
know
for
some
limited
subset
of
the
of
the
major
tools
that
we
use
and
look
we're,
never
the
whole
point
of
using
markdown.
It
is
grossly
simpler
than
xml,
so
there
will
never
be
bi-directional
between
the
two.
M
The
whole
point
of
markdown
was
not
to
have
as
much
accessibility
not
have
all
the
features
the
xml
had
right.
So
we
can't
look
for
a
technical
solution
to
map
between
those
two,
because
the
design
constraint
of
the
markdown,
what
makes
it
good
to
use
is
that
it
doesn't
have
that.
You
can't
do
that,
so
we
have
to
stay
out
of
trying
to
come
up
with
some.
You
know
pixie
magic
to
do
this.
M
We
should
just
look
at
the
normal
ways
that
everyone's
working
on
the
tools
we
have
today
and
what's
an
efficient
way
to
use
them,
and
it's
pretty
obvious
what
those
answers
are.
Yet
we
don't
seem
to
use
them.
We
use
them
in
the
working
group,
yet
we
don't
seem
to
use
them
between
this
this
process.
We
have
these
two
sort
of
isolated.
You
know
the
working
group.
Does
it
this
way
editor.
Does
it
this
way?
M
Maybe
both
of
those
are
fine,
but
when
they're
trying
to
work
together
which
they
are
in
this
late
stage,
we
have
to
find
a
way
to
do
that,
and
I
I
totally
reject
the
idea
that
you
know
the
rci
there's
a
black
box
and
can't
change
the
way
it
works.
I
mean,
obviously
again
so
thank
you.
B
Thank
you
paul.
K
So
a
couple
things
on
other
things.
People
have
said
I
think
ecker
was
being
too
conservative
when
he
said
you
know
we
can
only
work
on
like
one
or
two
for
that
that
the
rpc
could
only
work
on
one
or
two
formats.
Given
that
it's
all
text,
then
I
would
say
in
fact
any
editor,
at
least
in
my
experience
with
working
with
you
know
not
only
with
the
rpc
but
with
a
whole
bunch
of
different
book.
K
Publishers
and
stuff
can
handle
pretty
much
any
kind
of
text
format,
so
it
could
be
xml,
v2,
v3,
markdown
or
because
I
know
you
guys
still
get
plain
old
text.
It's
not
trivial
to
jump
between
those
mentally,
but
it's
also
not
difficult.
If
the
first
pass
is
the
editorial-
and
you
know
the
editorial
pass,
which
again
I've
seen
over
the
years,
I
thought
the
rpc
has
done
an
excellent
job
of
editing
when
it's
editing
and
putting
questions
when
it's
not
simple
editing
I
mean
that's
been
very,
very
clear
oftentimes.
K
If
I
was
going
to
be
critical,
I
would
say:
oh
that's
a
silly
question.
That's
just
an
editorial
question:
go
ahead
and
do
it,
but
that's
fine.
I
mean
I'm
not
saying
undo
that
so
I
disagree
with
jay
about
you
know.
Oh
a
person
goes
through
and
we
can't
expect
them
to
go
through
multiple
times.
We
don't
need
to
expect
to
go
through
multiple
times
the
output
currently
and
certainly
before
we
we
started
on
the
xml,
was
just
fine,
for
I
know
it's
editorial.
K
K
It
has
one
big
advantage
that
we
haven't
talked
about
here,
which
is
a
non-trivial
number
of
drafts
before
they
become
rfcs,
but
after
they've
passed,
the
ietf
review
get
significant
technical
changes
that
the
ietf
doesn't
get
to
review
where
in
in
some
cases
the
ad
gets
to
review
it,
but
the
isg
does
not,
and
quite
frankly
sometimes
this
has
a
pretty
negative
effect.
Certainly
on
the
morale
in
the
ietf.
When
people
go
well,
wait
a
sec,
you
guys
reverse
something
that
we
had
already
talked
about
in
the
working
group.
K
Oh,
it
was
done
in
auth
48..
So
I
like
robert's
idea
of
possibly
doing
some
of
this
and
having
the
isg
sign
off
on
something
that
is
probably
going
to
then
mostly
be
formatted
only.
I
suspect
it
won't
work.
I
suspect
that
that
there
will
be
too
much
clogging
factor
and
it's
going
to
make
the
isg's
life
much
harder,
but
I
wouldn't
mind
seeing
the
experiment
done,
because
I
do
think
that
for
the
rare
cases
where
it
happens,
where
you
get
technical
changes,
it's
pretty
important.
K
An
alternative
to
at
least
to
fix.
That
problem
is
that
everything
that
the
rpc
calls
out
as
a
question
should
be
reviewed
by
the
aed
and
in
a
perfect
world
should
be
reviewed
by
the
working
group.
If
it's
a
working
group
document
or
by
the
iab,
if
it's
an
iab
stream
document,
I
don't
think
everyone
needs
to
look
at
the
grammar.
But
since
you
guys
are
you
guys,
meaning
the
rpc,
I'm
sorry
to
misgender.
All
of
you.
K
I
think
the
the
rpc
is
already
pulling
out
questions
quite
well,
and
anybody
in
the
working
group
who
cares
could
look
through
those
and
look
at
the
results.
I
mean
that's.
The
nice
thing
we
have
now
is
that
if
there's
a
series
of
questions
and
the
authors
have
come
up
with
an
answer,
you
can
look
at
the
version
before
they
came
up
with
the
answer
and
the
version
after
and
say
yep
that
did
not
change
anything
technically.
E
I
think
if
we
have
the
case
where
a
document
has
more
than
trivial
changes
between
what
was
sent
to
the
isg
and
what
was
set
to
the
rfc
editor,
we
absolutely
should
just
require
a
new
internet
drive
to
be
published
because
that's
the
way
the
itf
works,
and
then
people
can
just
look
at
the
diffs
of
the
internet
drafts
and
that's
how
it's
supposed
to
work
and
if
we
have
changes
that
are
critical,
just
saying
the
idea
proved
it
and
it's
probably
okay.
E
E
Specs
we
have
a
two
chain
that
actually
extracts
the
abnf
checks,
the
abnf
reformats,
the
abn
f,
inserts
them
as
appendix
we
have
auto
generation
of
index
tables
and
so
on,
and
that's
obviously
very
hard
if
the
production
center
wanted
to
use
that
to
change.
That,
obviously,
would
be
very
hard
and
we
can't
ask
them
to
do
that.
E
So
here's
a
thought
experiment
if,
let's
say
a
working
group
had
the
two
chain
implemented
in
a
way.
That's
it's
a
github
action
and
that
you
submit
a
pr
against
the
source
document
and
then
can
see
what
comes
out
of
that.
E
Would
it
be.
I
mean,
for
the
editing
step,
a
potential
experiment
to
just
say:
we'll,
send
a
pr
with
the
editorial
changes
and
to
your
source
repository
and
see
what
happens
instead
of
doing
that
on
the
converted
xml
file
in
edits
in
the
edit
phase
that
the
authors
can
see.
B
I
guess
working
in
markdown
or
xml
and
then
we
do
a
pull
request
with
all
of
our
changes
like
submitting
our
auth
48
xml
file
as
the
pull
request.
Or
are
you
thinking
that
we
make
the
edits
and
and
multiple
sorry
need
some
more
details
on
on
the
experiment,
you're
proposing.
E
Yeah,
so
I
I
think
if
we
look
at
the
pure
copy,
editing
phase,
so
my
assumption
is
and
correct
me
if
I'm
wrong.
Somebody
in
your
group
starts
reading
the
document
and
either
takes
notes
or
starts
to
correct
typos
and
editorial
problems
right
away,
and
that
may
take
one
or
two
days
or
or
more
with
a
complex
document.
E
B
Basically,
yes,
a
couple
of
different
editors
work
on
the
document
and
we
are
working
in
one
document
and
then
it
is
released
in
all
48.
E
And
my
proposal
would
be
to
actually
where
technically
possible
and
I'm
not
saying
it
needs
to
be
cram
down
or
xml,
because
it's
an
experiment
where
it's
possible,
I
mean
we
could
run
this
experiment
for
this
small
document.
First
to
actually,
instead
of
editing
it
in
place
in
your
office
to
actually
submit
one
or
several
pull
requests
to
the
original
well
gets
repository
and
let
the
authors
merge
that
and
then
let
them
produce
a
new
document
from
where
you
can
then
start
the
auth-48
phrase.
E
B
F
Yeah,
I
just
wanted
to
respond
to
a
couple
points
jade
made.
I
mean
so
like
as
much
what
colin
said.
I
agree
with
this
is
like
professional
function,
and
but
you
know
it's
not
like
virtual
book
publishing
where
you
know.
If
I
do
something
addison
wesley,
I
must
have
take
their
process
or
leave
it.
We're
like
the
primary
customer
for
the
service,
and
so
that
means
like
that.
You
know,
within
the
bounds
of
reason,
we
have
a
certified
controller.
How
it's
executed
in
particular.
F
Like
you
know,
as
I
said,
traditional
publishing
does
have
a
multi-path
structure,
so
I
don't
think
it's
reasonable
to
ask
for
multi-pass
structure
here.
Also
in
terms
of
change,
control
switch
is
really
quite
nuanced
right.
It's
sometimes
the
case
that
the
publisher
takes
final
control,
but
I
produce
documents
on
a
book.
F
In
fact,
where
I
produce
camera-ready
copy
everybody's
pdf
and
they
printed
out
the
pdf,
like
you
know,
directly
on
their
offset
printers,
and
so
they
never
had
to
go
to
anything
and
they
sent
me
marked
up
paper,
I'm
not
suggesting
we
did
here,
but
I
mean
the
fact
that
these
are
mechanical
tools
that
we're
using
the
same
rough
tools
to
generate
the
output,
as
in
the
final
publication
stages,
we
do.
Ordinarily,
like
means
is
a
much
more
complicated
demonstration
than
traditional
book
publishing
or
maybe
they're
they're.
F
You
know,
maybe
you're
writing
a
word
and
they're
printing
in
frame,
and
so,
like
I
heard
earlier
this
session
that,
like
there,
should
be
a
difference
that
a
tool
changes
to
produce
the
final
documents
than
we
used
it
at
ours.
That
would
like
be
a
huge
regression.
The
fact
that
we
already
have
this
goofy
situation,
where
authors
are
writing
one
version,
sml
e3
and
it
gets
prepped
out
in
some
other
version
and
published,
is
like
already
a
problem.
We
should
try
to
revert
that
not
move
forward.
B
Thanks
so
we're
down
to
nine
minutes
rich,
really,
really
quickly.
I
Yeah
very
quickly,
I
just
want
to
add
a
gloss
to
paul's
comments,
which
is
the
area
director
is
probably
the
wrong
person
to
overload
with
feedback.
The
working
group
chair
is
less
loaded
and
more
incentive
to
get
documents
out
and
more
focused
on
what
the
working
group
content
is
and
is
probably
in
a
better
position
to
say.
Oh,
this
is
a
technical
change.
It
would
affect
that.
We
should
take
a
step
back
and
re-review
thanks.
I
B
Thanks
and
julian
sorry,
we
had
cut
the
cue
so
very
briefly
I'll
skip
to
the
end
of
the
slides,
but
so
we
focused
more
on
on
benefits
and
features
and
we're
discussing
at
a
very
high
level
what
people
the
issues
people
had
month,
48
and
what
they
would
like
to
see
different.
B
So
we
did
not
touch
on
whether
we
should
be
using
git
or
github
or
gitlab,
or
google
docs.
Even
we
have
not
talked
about
well,
we
did
talk
a
little
bit
about.
Should
you
know
the
editor
participate
in
the
author's
repo
julian
had
recommended
that
as
an
experiment,
we
did
not
get
to
the
can.
B
We
do
this
for
everybody
and-
and
this
was
down
in
the
details
like
if
we
were
talking
about
github,
although
I
guess
we
did
talk
a
bit
about
what
these
the
the
diff
should
look
like,
and
people
were
wanting
to
see.
Perhaps
multiple
passes
from
the
the
rpc
on
their
documents,
all
right
so
word
to
the
wrap
up
so
skimmed
over
what
we
did
not
talk
about,
and
so
what
I
was
hearing
from
a
let
me
go
through
my
notes
on
and
summarize.
B
B
Now
we
talked
about
a
lot
of
stuff
and
I'm
trying
to
figure
out
what
some
of
our
next
experiments
might
be.
Julian
did
say:
let
you
know,
let's
see
if
we
can
plan
an
author's
repo
is
there?
B
Does
anyone
have
other
suggestions
for
a
small
experiment
with
some
of
the
things
discussed?
I
see
ecker
and
paul
are
in
the
queue
ecker.
K
I
know
it
was
my
idea,
so
I
feel
weird
about
suggesting
it,
but
it
seemed
like
my
idea
resonated
of
doing
doing
an
editorial
pass.
First
of
some
sort.
Having
have
I'm
seeing
there's
a
bunch
of
thumbs
up
here
since
you
don't
have
your
camera
on,
but
yeah
there's
a
lot
of
fun
that
that's
a
reasonable
experiment,
even
if
it
it
doesn't
go
all
the
way
to
where
you
went
with
the
github
experiment
of
doing
that,
and
then
seeing
how
that
affects
your
process.
K
You
know
it
may
turn
out
that
that
really
sucks
for
your
process,
and
that
would
be
good
to
know,
but
if
it
doesn't
suck.
I
think
that
that
would
actually
be
a
really
good
first
step
to
other
things
that
you
could
then
do
later
of
and
show
it
to
the
authors
this
way
or
include
these
people
or
whatever,
but
just
to
see,
if
flipping,
that
over
actually
works.
For
you.
M
So
I
think
you've
I
think
what
I'm
proposing
is
is
is
doing
more
of
what
I
think
you've
already
done,
but
I'm
very
confused
about
what
has
been
done.
So
the
idea
of
forking
a
source
repo
or
forming
a
new
github.
You
know
for
forking
the
source
repo
to
have
a
a
repo
that
is
under
control
of
the
rfc
editor
and
doing
the
changes
in
the
source
format
be
that
xml
or
markdown
and
and
working
with
the
collaboratively
using
the
github
series
of
tools.
To
do
that.
M
I
I
believe
you've
done
that
for
both
markdown
and
xml.
At
this
point,
I'm
sort
of
worrying
about
like
do
more
of
that
and
plus
one
the
editorial
path.
Separation
for
sure
I
mean
is
there?
Is
there
a
problem,
and
I
mean?
Was
there
an
outcome
in
that
experiment
that
suggested
we
shouldn't
be
doing
that
or
something
I'm
missing
here.
B
So
can
we
can
do
that?
We
can
iterate
on
the
the
most
recent
experiment,
which
was
9245
if
I've
got
the
rfc
number
right.
M
B
B
All
right
well,
thank
you
very
much
for
offering
your
ideas
and
suggestions.
I've
really
appreciated
your
time.
We've
got
a
lot
of
notes
and
we'll
be
writing
that
up
I'll,
be
we'll
update
the
hedge
doc
and
I'll
send
out
some
info
to
the
rfc
interest
list.
B
Any
other
questions
comments.