►
From YouTube: IETF104-GIT-20190328-1050
Description
GIT meeting session at IETF104
This tutorial held at 12:45-13:45 UTC on 24 March 2019 provided information about using Github for work in the IETF.
2019/03/28 1050
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
This
is
the
note,
well
I'm
sure
you've
seen
this
several
times
so
far,
so
note
the
usual
things
and
note
that
well
a
quick
overview
of
the
agenda
under
spend
I
mean
blue
sheets
are
floating
around
somewhere.
So
please
fill
them
out.
Once
you
get
them,
we
do
need
a
jabber
scribe,
so
I'm
hopeful
someone
will
raise
their
hands
volunteer
at.
A
B
So
review
or
revision
or
bashing
of
the
agenda.
This
is
basically
what
we
have
discuss.
A
couple:
I
guess
working
group
process
things
before
we
get
started
into
the
two
documents
that
we
have
on
plate,
the
first
one
of
which
is
a
working
group
that
dubbed
the
document.
Another
one
is
for
Martin
and
is
possibly
up
for
adoption
as
well,
so
I
see
again
coming
to
the
mic.
Could.
C
B
B
D
B
The
this,
the
procedure
by
which
we
would
start
doing
so
is
to
make
sure
that
the
work
group
is
actually
on
board
with
doing
this.
So
at
this
time,
I'd
just
sort
of
like
to
ask
the
group:
are
we
okay,
with
using
github
in
some
capacity
I'm,
not
specifying
exactly
what
capacity
it
says?
The
second
question
to
answer:
do
we
want
to
use
github
for
the
documents
adopted
by
the
working
group.
B
I
guess,
a
more
a
more
difficult
question
than
is
and
what
capacity
should
be
using
a
hook.
So
Martin's
document
describes
different
ways
that
working
groups
can
use
github
varying
from
I
guess
one
end
of
the
extreme
like
quick,
using
issues
and
pull
requests
to
drive
things
forward,
moving
to
lists
once
you
need
things
for
consensus
versus
using
github
as
a
way
to
just
track
documents
and
have
most
discussions
take
place
on
the
list.
B
So
the
proposal
we
have
for
us
right
now
is
to
have
the
working
group
documents
in
the
github
organization
on
github
file
issues
there,
but
make
just
have
all
substantial
discussions
take
place
on
the
list.
Considering
that
we
don't
expect
a
lot
of
term
much
like
quick,
it
seems
like
a
fairly
reasonable
proposal
to
at
least
the
chairs,
so
we'd
like
to
hear
what
the
work
motor
participants
think
of
this
idea.
E
D
E
With
github
and
that
and
that
world,
and
if
we
start
having
discussions
on
github
and
hiding
things
from
them,
we
might
end
up
with
surprises
and
I
would
rather
have
the
substantive
discussion
on
the
mailing
list.
I
realize
that's
the
conservative
approach
here,
but
I
think
it's
probably
appropriate
and,
as
you
said,
it's
not
going
to
be
hugely
high
traffic
on
the
documents
themselves.
I
think
we're
gonna
be
talking
about
most
of
that
stuff.
Today,
right.
C
Thank
you,
Brian
yeah,
for
animal
+12
that
working
in
two
working
groups-
you
know
one
quick
and
two
taps
or
the
which
use
github
I-
think
one
good
that
this
process
requires
a
little
bit
more
discipline
of
the
editors
to
be
able
to
say.
Okay,
this
issue
is
actually
crossing
the
line
move
it
over.
It's
worked
well
in
both
the
working
groups
that
I've
seen
it
in
one
additional
piece
of
tooling.
That
can
be
a
backstop
of
that
as
a
script
that
goes
by
and
posts
if
you
changes
summary
to
the
list.
C
F
Let's
lift
missed,
can
you
speak
a
little
closer,
say?
Okay,
although
I
understand
that
support
the
approach.
If
using
a
give
the
floor,
certain
side
problems,
event
amenities
for
the
substitute
discussion,
you'll
find
that
over
time
will
be
very
hard
to
separate
the
two.
Because
often
you
raise
an
issue
and
a
lot
of
substantive
discussion
happens
and
github.
It
will
require
a
lot
of
discipline
and
a
policy
setting
by
the
chairs
to
actually
make
it
happen,
but
good
work
but
I
think
it's
a
good.
A
E
I
think
the
point
was
well
made
about
the
fact
that
things
tend
to
bleed
into
those
issues,
and
people
tend
to
just
pile
on
on
issues.
We
had
this
experience
early
on
in
HTTP
2,
where
we
followed
a
very
similar
process
to
what's
being
proposed,
and
yes
initially,
it
does
require
a
little
bit
of
vigilance.
D
E
B
Reasonable
we're
willing
to
do
that
all
right.
So
hearing
no
objections,
we'll
just
we'll
go
forward
that
particular
process
file.
All
the
issues
on
the
github
documents
and
we'll
take
wait.
Oh
I
have
all
those
guys
should
take
place
on
the
list,
just
that
everyone
can
follow
along
those
not
familiar
with
the
the
tooling
and
the
process
of
using
github
to
the
extent
that
clicked
it
groups
like
quick
use
it.
So
the
next
order
of
business
is
on
tooling
and
projects
that
are
relevant
to
the
particular
working
group.
B
B
B
B
B
C
C
That's
what
I'm
asking
is
that
is
that
what
it
is?
Okay,
yes,
okay,
because
I
think
that's
the
piece
would
be
one
comment:
I've
had
from
people
who
have
been
working
trying
to
work
with
this.
Is
they
don't
understand
what
tools
are
available
to
work
with
IDs
and
things
we've
out
there,
so
whatever
documentation
or,
however,
we
can
prove
that
would
be
great
and
I
will
take
a
look
at
that?
Okay,
yeah!
Thank
you
yeah.
C
B
C
G
I
just
wanted
to
emphasize
the
and
their
documentation
piece
sort
of
to
what
Dan
was
saying,
but
I
think
for
some
parts
of
the
community.
The
hard
part
here
is
understanding
the
existing
tools,
not
that
they
need
more
different
tools.
So
if
there
are
volunteers
who
want
to
work
on
the
documentation,
I
think
that
would
be
most
welcome.
Are
you,
volunteering
Martin
I
thought
you
had
anti
volunteered
before?
A
So,
to
emphasize
that
wearing
a
different
hat,
I
was
editor
of
the
initial
RSC
beat
our
new
RFC
format,
the
v3
format,
and
one
of
the
things
we
heard
constantly
was
that,
yes,
there
were
tools
out
there
for
doing
interesting
things,
but
they
weren't
well
documented,
as
they
got
better
documented.
We
saw
a
rapid
ink
in
use
by
early-adopter
bike
people
other
than
early
adopters,
so
documentation
here
is
especially
important
for
people
using
the
tools
the
first
time.
A
H
B
H
Stark,
who
would
love
to
help
with
the
documentation
I've
actually
used
some
of
this
to
get
some
github
sites
up
and
running
for
it.
Two
of
my
working
groups
and
I've
actually
also
used
them
from
my
personal
repository
to
work
on
a
draft
and
as
someone
who
doesn't
do
code
and
doesn't
comprehend
how
to
read,
make
files
and
things
like
that
I
think
I
could
probably
be
really
useful
in
helping
provide
documentation
for
people
like
me,
because,
while
I'd
used
it,
what
I've
done
is
seriously
broken,
and
so
that's
good
thanks.
H
I
D
I
I
You
really
are
kind
of
on
your
own
for
figuring
out
how
to
get
stuff
all
up
and
running
how
to
get
the
notify
scripts
running
because
we
don't
have
a
unified
workflow
of
you
go
into
github
to
create
this
repo.
You
add
the
template
to
it,
you
hook.
Ups,
your
whole,
all
of
those
are
separate
tasks,
they're
documented
in
different
places,
and
not
all
of.
J
B
I'm,
just
going
to
point
out,
you
have
mark
Martin's
document
does
describe
how
to
set
up
circle,
but
to
your
point
yet
some
of
the
documentation,
scattered
and
it'd
be
nice
if
it
could
be
collated
in
a
single
place
for
everyone
to
use.
So
can
I
just
get
a
show
of
hands
from
folks
in
the
room
who
would
be
interested
in
potentially
helping
develop?
Slash,
maintain
slash,
ed
documentation,
slash
comment.
B
This
so
I
should
pretty
much
help
with
this
overall
effort
cool.
How
that
actually
take
place.
You
don't
really
have
a
specific
process
in
mind.
I
minimally,
you
know,
take
a
look
at
the
tools
tried
file
issues
for
a
groovy
documentation
right
now,
and
perhaps
we
can
Paul
and
I
can
go
off
and
think
of
something
more
formal
if
we
need
to,
but
just
start
using
them
and
tell
the
folks
who
maintain
them
essentially
what's
wrong
with
them
and
how
they
can
be
improved.
That
would
be
at
least
a
way
to
get
certain
so.
A
And
as
a
note
on
this,
the
this
is
tooling
not
a
kind
of
software
that
you
might
expect
in
github.
So
an
issue
of
I
don't
understand
how
to
do.
This
thing
is
a
perfectly
reasonable
issue,
whereas
you
would
normally
get
jumped
on
and
get
up
for
a
comment
like
that.
That's
actually
valuable
here,
because
we
had
a
fair
smattering
of
hands
and
people
who
said
that
they
were
willing
to
do
documentation
even
an
issue
of
I.
Try,
I
I
got
halfway
through
the
tool
and
then
I
stopped.
Because
of
this.
That's
just
fine.
B
G
Oh
there
we
go
okay,
so
there
three
changes
the
first
one
was
slight
modification
in
the
abstract
so
before
it
used
to
say
that,
though,
foreign
group
does
not
intend
to
change
the
processes
used
by
current
working
groups,
there
was
a
little
bit
of
lack
of
clarity
about
whether
this
meant
that
working
groups
that
are
currently
using
github
could
change
their
processes
to
align
with
whatever
we
produce
here.
If
they
wanted
to.
So
we
changed
this
so
now.
G
The
second
change
was
about
adding
a
sentence
to
note
the
existence
of
other
code
repository
services
made
possibly
with
different
properties.
There
was
some
discussion
on
the
list
about
this,
and
people
wanted
it
to
be
noted
in
this
in
this
draft
and
though
this
drafts
specifically
about
github
and
then
lastly,
we
had
this
old
note
that
was
in
there
about
needing
to
research,
the
API
for
connecting
personnel
into
the
data
tracker
and
the
tool
scheme
can
work
on
this.
We
don't
need
it
to
be
noted
in
the
draft.
G
K
E
B
E
E
Tonight
so
yeah
one
of
the
critical
questions
I
think
in
discussing
this
will
be
the
relationship
between
the
two
drafts
that
we
talked
about.
So
I
set
things
up
a
little
bit,
so
I
want
to
talk
a
little
bit
about
what
I,
why
I
put
the
document
together
and
how
it
sort
of
approaches
its
discussion?
The
goal
of
this
is
largely
to
describe
how
things
work
why
they
might
interact
with
those
things
it's.
E
It
spends
a
lot
of
time,
carving
up
various
areas
where
there
be
dragons,
because
I
think
that's
one
of
the
one
of
the
things
that
is
particularly
dangerous
in
this
area.
There's
a
lot
of
there's
other
ways
you
can
use
these
tools
that
don't
work
productively
and
so
well
and
so
having
a
lot
of
documentation
on
the
things
you
might
think
would
be.
A
good
idea,
but
aren't
really
in
practice,
is,
is
very
useful,
I
find,
and
that
means
that
it
as
a
general
thing,
the
document
tries
to
sort
of
guide
people
towards
particular
approaches.
E
It
doesn't
have
any
strict
template
or
saying
here's
the
things
that
you
will
do
it
simply
says.
If
you
do
these
things
and
understand
that
these
have
these
consequences-
and
you
might
want
to
do
this
as
a
thing,
so,
if
we're
talking
about
documenting
processes,
the
current
formula
document
isn't
entirely
suitable
for
that
sort
of
thing,
but
it
does
provide
a
lot
of
information
for
someone
who's
who's.
Setting
this
this
process
up
to
make
their
own
choices.
D
E
E
In
a
past
life
I
spend
quite
a
lot
of
time,
doing
Quality
Assurance
training
and
until
9000
certification,
all
those
wonderful
things
and
part
of
the
approach.
There
was
that
you
would
have
a
continuous
evolution
of
the
processes
that
you
have,
and
one
of
the
philosophies
that
I
learned
in
that
was
that
you
capture
what
you're
doing,
rather
than
what
you
might
aspire
to
be
doing,
and
that's
another
aspect
of
this
one
that
I
think
we'll
have
to
be
aware
of
as
we
as
we
go
into
this
I.
E
E
Realized
that
I've
talked
about
this
document
in
its
various
versions,
twice
presented
on
it
and
I've
never
actually
gone
through.
What's
in
it,
I
think
we've
been
talking
about
other
things
in
relation
to
that,
so
I
thought
I'd
give
a
little
bit
of
an
overview.
What's
what's
going
on
here,
have
a
sort
of
high-level
there's
some
mechanical
parts
to
it,
sort
of
how
they
ITF
and
github
an
erection
was
well.
Did
you
have
a
question
you
want
to
ask
now
what
you
want
to
hold
it
off,
for
it.
L
Was
Robert
sparks
is
to
comment
on
point
you
made
on
your
last
slide.
Show
up
not
documenting
details,
I
think
that
it
would
be
useful
to
you
capture
the
details,
but
just
frame
them
as
at
this
time
the
following
happen,
because
you
will
have
people
come
back
in
five
years
or
ten
years
and
look
at
this
and
try
to
understand
how
things
evolved
and
it.
I
E
E
So
there's
there's
a
bunch
of
the
document
that
deals
with
sort
of
mechanics
of
the
interactions
making
organizations
and
assigning
permissions
to
people
and
whatnot.
There's
a
bunch
of
things
about
how
you
bootstrap
this
process
and
how
the
working
group
decides
to
to
do
this
and
the
policies
that
the
working
group
might
might
evolve.
E
There's
a
chunk
of
discussion
about
the
the
features
that
are
available,
how
you
use
them
the
pitfalls
that
are
inherent
in
that
use,
and
some
guidance
after
that
that
sort
of
walks
through
some
of
the
other
things
as
a
tile
section
on
assessing
you
know
how
you
manage
the
consensus
process
with
a
tool
like
this
and
there's
an
other
discussion
about
advising
editors,
for
instance,
on
on
what
would
be
a
good
practice,
southern
sort
of
structural
stuff.
There's
a
considerable
overlap
between
this
and
the
document
that
Alyssa
and
Paul
have
put
together
on
this
one.
E
E
My
proposal
here
is
to
try
to
remove
as
much
of
this
stuff
from
the
document
as
possible
and
move
it
over
to
the
other
document.
I
think
most
of
the
this
is
strictly
duplicative.
At
the
moment
there
may
be
a
few
a
few
things
that
we
need
to
look
at,
but
I'd
like
to
make
sure
that
we
do
that.
So,
if
anyone
disagrees
with
me,
I'd
like
to
hear
that
excellent
do
as
I
say,
speaking
of
doing
as
I
say
the
process
that
a
working
group
might
you
go
through
to
decide
to
use.
E
E
But
there's
there's
a
small
section
in
here
that
talks
about
the
process
by
which
a
working
group
I
might
do
that
and
the
the
various
trade-offs
that
you
might
make
some
of
the
discussion
that
we
just
just
had
during
chrises
presentation
here
and
so
for
me,
I'm
interested
in
asking
the
question:
how
specific
should
we
be
in
in
this
advice?
Currently
it's
fairly
loose
and
it
could
be
more
specific.
We
could
do
things
like
saying:
well,
here's
a
particular
playbook
as
it
were,
we're
following
the
the
light-touch
playbook
cause.
E
A
We
can
open
the
open
the
lines
on
this
one
from
them
from
the
mailing
list.
I
think
those
were
the
two
main
choices.
That's
the
impression
I
get
as
well
yep.
So
far,
there
might
be
more
later,
but
I
think
that
that's
a
reasonable
start,
and
one
thing
that
I
heard
this
week
off
list
was
somebody
saying
we're
thinking
of
getting
you
know
of
doing
it.
I
think
we'll
end
up
heavy,
but
if
we
start
light
we'll
be
able
to
figure
out
how
to
go
from
light
to
heavy.
A
E
H
So
it's
been
Barbara
stark.
It's
been
my
experience,
so
in
broadband
form,
we've
been
doing
a
lot
of
things
with
all
the
atlast
and
stuff,
so
we've
got
the
bit
bucket
and
all
these
other
things
and
trying
to
educate
people
kind
of
similarly
do
I
think
what
you're
trying
to
do
here
that
we
don't
have
all
these
expensive
tools.
But
you
really
need
someplace
like
a
readme
MD
and
instructions
there
that
are
living
document
and
I.
H
Think
a
lot
of
the
things
you're
talking
about
here
really
need
to
be
in
a
living
document
that
as
tools
change,
because
the
tools
are
going
to
be
changing
regularly
and
you
need
to
update
your
document
regularly
and
as
people
have
questions,
you
need
to
update
all
that
regularly
and
I.
Think
a
lot
of
what
you're
talking
about
here
really
needs
to
go
and
that
sort
of
thing
and
not
in
a
static
document.
E
G
G
Might
be
candidate
for
that,
but
I
think
it
is
be
really
useful
to
separate
that
the
pieces
that
people
do
think
are
going
to
be
dynamic
and
continue
to
change
and
the
pieces
that
are
not
like
I.
Just
think
about
this
slide
is
called
deciding
to
use
github
like,
hopefully
the
the
little
bit
in
the
draft
which
actually
talks
about
how
to
decide.
It
is
not
going
to
change
a
lot
then
it's
like
what
the
choices
are
and
all
that
like
that,
might
change
right.
G
So
I
can
see
that,
but
there's
also
a
substantive
separation
in
those
things
like
one
of
these
is
about
like
how
does
a
working
group
run
itself
sort
of
like
BZ,
p25,
update
kind
of
thing,
and
then
the
other
is
like
here's,
a
bunch
of
things
that
they
could
choose
to
do
once
they've.
They
are
following
the
process
of
how
they
run
and
I.
Think
keeping
those
conceptually
separate
will
be
useful
to
get
this
to
get
the
part
that
does
need
to
become
an
RFC
advanced
through
the
idea.
G
A
A
G
No
other
work
group
that
wants
to
use
living
documents
wants
that
to
happen
either,
presumably
because
that's
kind
of
the
point
like
it's,
it's
very
meta,
like
the
people
who
really
want
to
do
living
documents,
definitely
don't
want
to
like
wait
for
some
process
so
that
they
can
do
living
documents
so
like
this
is
extremely
preliminary.
Like
I
didn't
even
ask
the
IHG.
If
I
could
talk
about
this
before
I
came
to
the
microphone,
because
we've
literally
like
only
exchanged
a
few
emails
about
it,
but
we
haven't
talked.
D
B
G
Since
Bank,
so
I
can't
really
tell
you
much
about
what
the
shape
of
this
is
gonna
be
because,
like
I,
might
walk
into
the
ISU
meeting
tomorrow
and
everybody
says
we
hate
this-
we
don't
want
to
do
it,
but
I
think
if
it
if
it
starts
to
look
like
this,
we'll
get
hung
up
then
like
just
leave
it
in
a
draft.
A
draft
is
great.
A
draft
is
a
living
document
that
you
can
update
any
time,
so
it
need
not
get
hung
up
on
that.
Okay,.
A
Good
because
I,
just
having
lived
through
the
wars
of
saying
having
an
IAS
G
literally
20
years
ago,
tell
us
russ
has
lee
and
I
keep
a
living
document
and
we
did
and
then
we
got
beaten
up
for
it
later
when
it
when
it
finally
got
instantiated
I,
don't
want
that
to
happen
here,
because
that
would
be
a
really
bad
example
for
exactly
the
topic
that
we
have
here
so
okay.
So
we
might
keep.
Even
if
the
working
group
closed
down,
we
might
keep
a
draft
alive
until
the
you
know.
M
N
N
E
But
if
you
wanted
to
create
a
process
document
that
there
was
a
little
higher
level,
then
it
would
look
like
a
much
reduced,
not
only
being
a
couple
of
pages,
and
we
don't
have
to
deal
with
that
very
very
much.
But
the
that
document
as
an
update
to
IRA
see
what
would
be
CP,
25
I,
think
you
said
I,
don't
remember
all
the
numbers,
but
an
update
to
that
or
something
that
was
related
to.
That
would
be
possibly
a
good
thing
to
consider
doing.
I,
just
don't
have
one
right
now.
E
So
the
next
topic
is
well
there's
a
bunch
of
stuff
in
the
in
the
draft
that
falls
in
that
category
of
things
that
are
far
too
specific
to
really
want
to
pin
down
at
this
point-
and
we
might,
we
may
give
the
document
in
draft
form
for
some
extended
period
of
time.
Just
so,
we
can
get
more
experience
with
these
things
and
it
talks
about
issues
and
pull
requests
and
do
you
use
the
wiki
and
continuous
integration
and
always
sorts
of
other
things
and
they're
going
to
be
very
specific
to
the
tools
that
you
have.
E
There
are
two
sections
in
here
who
has
some
discussion
on
the
list
about
the
consensus
pieces
of
it
I
think
there's
some
there's
some
work
to
be
done
here.
I
think
the
original
versions
of
the
document
sort
of
took
this
laissez-faire
approach.
Where
you
can
do
whatever
you
want
with
the
documents
which
is
fairly
consistent
with
the
way
that
documents
are
developed
prior
to
this,
but
it
sort
of
said
that,
well,
you
know,
stuff
happens
on
the
document,
and
editors
make
some
sort
of
decisions
on
on
what
goes
in
and
out
of
the
document.
E
And
then
you
come
to
the
back
to
the
working
group
and
ultimately,
the
working
group
is
a
backstop
on
this
thing.
Any
who
can't
even
imagine
saying
that
working
group
last
call
is
the
time
when
you
make
the
final
assessment
about
whether
there's
consensus
on
any
given
thing.
The
thinking
has
evolved
a
lot
past
that,
and
so
we
have
we've
moved
from
the
models
that
we
have
active.
This
active
discussion
on
the
on
the
document
and
consensus
to
merge
things
various
stages
of
the
lifetime
of
the
of
the
document
changes.
E
So
you
can
imagine
that
if
you've
got
an
individual
draft,
the
obviously
the
editors
and
authors
of
an
interview
draft
are
just
gonna
dump,
whatever
they
want
in
there,
regardless
of
what
the
working
group
thinks,
because
they're
not
that
of
their
business
once
something
becomes
a
working
group
draft.
Is
that
there's
a
little
higher
bar
for
that,
and
one
of
the
things
we
discovered
with
with
quick
in
particular,
was
that
there
was
a
need
early.
D
E
This
process
to
to
give
considerable
leeway
to
editors
in
making
decisions
about
what
it
was
that
went
in
the
document
and
what
what
was
left
out
and
then
we
had
sort
of
these.
These
attempts
at
processes
to
to
sort
of
retro
actively
bless
the
things
that
were
in
in
the
document,
and
it
gets
really
kind
of
complicated
and
fairly
confident
saying
that
most
people
didn't
really
understand
what
was
going
on
and
what
had
consensus
in
what
didn't
have
consensus.
E
What
I
think
we
heard
was
consensus
that
that
that
the
documents
were
largely
headed
in
the
right
direction
that
we
wanted
to
work
on
the
protocol,
but
there
wasn't
a
whole
lot
more
than
that,
and
so
we're
sort
of
come
to
the
realization.
There's
multiple
stages
in
the
life
cycle
of
the
document,
where
different
processes
that
are
approach,
and
so
the
the
the
draft
at
the
moment
doesn't
really
capture
this
very
well
and
I.
Think
we
need
to
spend
a
little
bit
of
time.
Thinking
about
how
that
works.
E
Right
now
and
quick,
we've
moved
to
a
far
more
formal
process
where
the
documents
are
considered
to
embody.
The
current
consensus
of
the
document
absent
any
issues
that
the
editor
that
the
working
group
chairs
agree
our
open
issues
on
the
document
there's
a
kind
of
interesting
process
to
be
in,
but
it
means
that
you
have
essentially
consensus
on
all
the
bits
of
the
document
that
have
that
are
done,
plus
all
of
the
things
that
are
broken.
E
But
it
was
that
was
informal.
We
didn't
have
any
real
recognition
that
we
were
transitioning
between
between
one
phase
and
another
I
think
this
is
generally
how
documents
are
developed
once
they
get
more
mature
in
in
the
process.
We
sort
of
see
people
being
more
sensitive
to
change
and
be
more
proactive
in
gaining
working
group
consensus
and
relying
more
excuse
me
on
the
on
the
judgment
of
chairs,
but
this
thing's
a
little
bit
more
work.
So
I
guess
Mike.
You
have
some
insights.
I
O
O
Project
boards,
I
guess
a
year
or
so
ago,
and
and
it's
lots
of
fun
your
your
game
of
flying
this,
it's
really
cool
I-
would
encourage
people
to
try
it
out,
but
we
introduced
that.
Do
this
specific,
largely
due
to
the
specific
situation,
the
quick
sanding
that
our
Charter
says.
We
start
with
these
documents,
but
we
explicitly
don't
have
consensus
on
their
contents,
and
so
we
needed
a
way
to
flip
from
that
state
to
documents,
reflected
consensus
and
that's
why?
One
of
the
reasons
why
the
late
stage
process
was
introduced.
O
O
Let's
get
it
out
in
the
world
and
that
does
create
sometimes
a
bit
of
a
nightmare
situation
where
you
have
this
ever-increasing
set
of
issues,
because
people
have
an
idea
in
the
middle
of
the
night
or
on
the
toilet
or
whatever.
So
that's
that's
one
of
the
reasons
why
you
have
a
bar
for
for
accepting
those
for
discussion
than
working
group.
We've
always
said
in
HTTP
as
well
as
in,
but
the
issues
list
is
a
mechanism
that
the
chairs
and
the
editors
used
to
manage
the
conversation
in
the
state
of
things
in
the
world.
E
E
If
you,
if
you
insist
on
working
group
consensus
before
making
any
change
to
the
document,
you
you
end
up
in
complete
paralysis,
particularly
early
on
in
the
process,
but,
like
I
said
it's
it's
a
tool
that
we
use
for
editors
and
chairs
to
manage
this
manage
the
the
outstanding
work.
It's
not
not
really
the
the
final
arbiter
of
consensus
that
that's
the
process
that
ultimately
happens
in
the
working.
A
E
There's
a
little
text
on
there
for
the
benefit
of
the
heavy
weight
process,
specifically
because
it's
far
more
complicated
but
those
groups
that
I've
been
in
that
that
do
exactly
the
process
that
you
talked
about,
make
the
decision
and
then
just
use
the
issue
to
track
them.
I
think
that's
already
covered
in
here,
and
maybe,
if
I
can
get
you
to
read
it
again
and
direct
specific
comments
at
it.
That
would
be.
That
would
be
good
will
do,
but
it
is.
E
A
C
Like
not
like
removing
that,
like,
like
as
a
disservice
to
people
who,
like
we'd
like
to
recollect
that
working
groups,
unless
it
can,
we
people
were
able
to
run,
give
up
or
any
mark
Nottingham
and
Sean
Turner,
so
so
I
don't
think
we
should
remove
it.
I
I
do
think
I
do
think
it's
useful
to
sort
the
stage
of
like
you
know
the
sort
of
to
Orchestra
to
extreme
up
right.
What
extrema
is
that
github
is
purely
like
a
coordination
tool,
and
you
know,
and
all
consensus
is
to
clear
like
entirely
enlist
with
no.
C
You
know
you
know,
but
we're
you
and
there's
another
one
where,
like
the
practical
matters,
extremely
hard
like
me
gauge
without,
like
you
know
with
it
without
you
know,
engaging
weekend
right
and
like
I
mean
quick
and
TLS
like
it's
gotten
extremely
hard
to
like,
engage,
pushing
quick
without
like
having
some
get
up.
We
get
into
engagement,
I
mean
you
know.
Certainly
it's
technically
true,
like
you
just
read
the
documents
as
they
came
out
but,
like
you
know,
like
you,.
P
Yet
rich
solve
yeah,
rich,
rich
sauce
guru,
there
Decker
said
also
for
groups
that
want
to
get
further
along
on
the
learning
curve
or
adoption
figuration
with
github.
As
you
said,
this
is
hard
learned
and
knowledge
and
it
shouldn't
disappear.
The
ether
there
are
people
who
will
not
want
to
do
it,
and
maybe
we
need
to
put
more
disclaimers
that
there's
no
requirement
you
do
this
if
you're
concerned
about
using
you
know
a
Microsoft
owned
resource
to
manage
some
of
your
workflow.
Don't
do
that?
Just
do
this
part,
but
yeah,
don't
don't
move
this.
D
E
E
E
Does
this
have
approximately
the
right
scope
with
modulo
the
the
movement
of
all
of
the
structural
stuff
to
the
other
document?
Is
it
worth
publishing?
Will
we
have
had
that
discussion
and
is
it
this
working
group
where
we
it's
most
appropriate
to
do
that
so
I'll
leave
this
with
one
with
the
chairs.
I'm
gonna
go
and
sit
down.
B
Right
so
can
I
get
a
quick
show
of
hands
as
to
who's.
Read
this
particular
document.
I
guess
any
version
of
it:
okay,
pretty
decent
amount.
It
seems
certainly
like
something
that
would
benefit
the
community
for
numerous
reasons,
especially
given
that
it
sort
of
correlates
all
the
saying
harder
about
hard
hard,
the
knowledge
that
we
had
you
know
a
long
time
ago,
a
very
quick,
yes,
thank
you.
It's
Thursday.
B
So
to
that
point,
I
think
I'd
like
to
ask
the
working
group.
If
we
think
this
document
should
be
adopted,
given
the
current
scope
of
the
material,
that's
in
there
right
now,
which
does
contain
some
advice
for
the
light
and
heavy
variance
of
the
groups
who
would
like
to
use,
it
doesn't
dictate
any
particular
profile
for
groups
who
want
to
use
it.
It
simply
just
tries
to
guide
people
along
the
path
that
is
best
for
them
in
their
particular
working
group
for
their
particular
process.
So
question
will
be.
B
E
B
Sort
of
was
taken
assuming
that
the
the
material,
especially
through
that
overlaps
with
the
the
configuration
document,
would
be
removed.
There
was
no
violent
objection
to
that
and
seemed
silly
to
have
the
information
duplicated.
So
yes
to
your
point,
yes,
the
the
information
can
change,
especially
because,
as
a
community,
we
are
still
learning
how
to
use
github
effectively.
B
Github
might
change
features
that
influence
what's
actually
written
down,
for
example,
with
the
issue
tracker
just
be
completely
removed
in
favor
of
this
can't
bad
sass
poor
thing,
whatever
yeah
things
may
change,
but
the
question
remains:
should
the
working
group
have
a
document
of
this
variety
that
sort
of
tries
to
document
this
information
and
advice
for
the
benefit
of
other
people
trying
to
use
it
in
either
light
or
happy
mode?
So
if
anyone,
no
one's
going
to
get
up
to
ask
a
question,
I
will
just
ask
the
question
now.
A
B
All
right,
so
we
will
adopt
it
Martin.
Well,
it's
been
a
new
version
for
the
work
group
and
we
can
move
forward
with
it
and
we
ask
that
people
who
especially
people
who
are
you
know
using
github
in
the
light
variant.
Please
review
it
provide
suggestions
as
issues
and
discussion
on
the
list
regarding
ways
in
which
that
particular
advice
could
be
improved
either.
B
In
terms
of
you
know,
turning
off
or
maybe
perhaps
turning
down
or
changing
some
language
around
the
heavy
profile
that
such
that
doesn't
turn
away,
people
who
want
to
use
it
for
the
light
variant
or
whatever.
Certainly
we
want
to
make
sure
that
the
information
that's
available
for
any
you
know
potential
user
of
github
as
maximally
useful
for
so.
A
I
am
only
active
in
working
groups
that
are
in
the
light
mode,
and
it
seems
like
the
most
active
people
here
are
in
working
groups
in
the
bleeding
edge
mode,
and
it
would
be
great
if
there's
anyone
here
now,
who
is
also
in
the
light
mode,
but
we
will,
we
will
actively
seek
out
working
group
chairs
to
contribute
to
how
they
are
using
now
or
how
they
would.
You
know
just
like
to
start
be
using.
G
So
we
can
see
like
how
much
of
how
much
material
is
there
really
for
a
visa
b25
update
if
it's
like
three
normative
statements,
or
it's
like
more
than
that
and
then
and
then
figure
out,
it's
like
splitting
that
off
makes
sense
or
not
and
I
think
if
it
does
get
split
off
advancing
the
configuration
document
and
the
BCP
25
update
at
the
same
time
would
probably
be
most
helpful
for
the
community's
understanding
of
what
what's
going
on
here.
Yeah.
A
Know
process,
but
if
it
becomes
clear
that
we're
changing
IETF
processes
working
need
a
much
larger
room,
regardless
of
how
many
people
signed
the
blue
sheet
and
I
would
rather
and
as
chair
I,
would
rather
that
not
land
in
our
lap.
We
might
say
here
are
some
things
that
are
useful
for
that,
but
I
would.
Rather,
if
there's
a
document
coming
out,
that's
going
to
actually
change
ITF
process
that
it
not
come
did
not
be
discussed.
This
working
group
that's
going
to
be
an
attractive
nuisance.
E
So
so
the
the
charters
kind
of
kind
of
says,
don't
change
what
we're
doing
in
2026.
I,
don't
see
it
as
any
of
that
I
see
as
this
is
adding
in
to
the
set
of
processes
of
the
organization
operates
by
not
not
changing
any
of
you.
The
existing
ones
and
I
think
that's
a
little
that
the
Charter
I
think
of
miles
for
that.
So
I
think
the
mistake
was
saying
we
were
talking
about
an
update
to
basically
25.
O
G
Because
these
b25
is
one
that
we
have
about
working
group
processes
right
so
I
think
Martin
is
correct,
with
like
adding
adding
more
process
to
what
working
groups
can
do
like.
It
probably
should
be
an
update
to
be
tonight
actually
update,
PCP
a
update
RFC's
anyway.
We're
gonna
need
to
talk
about
it,
but
I
think
I
think
we
can
add.
You
know,
there's
like
adding
guidance
to
what
working
groups
can
do
is
a
fine
thing
for
this
order
to
do
it
seems
to
be
within
the
Charter
and
we're
not
changing
the
standards
process.
Okay,.
C
E
Neither
new
topic
so
I
was
just
waiting
to
see
that
one
the
bit.
Does
anyone
want
to
volunteer
to
co-author
this
document
with
me
just
putting
that
out
there
well
there's
a
large
audience
and
see
mark
not
again
volunteering
right
there,
excellent,
oh
yeah!
That
was
a
volunteer
that
wasn't.
If
no
one
else
does
I
will
for
the
minutes.
Oh
rich
is
gonna
say
that
to
you
to
can
fight
each
other
food.
A
J
C
Mean
like,
while
I
think,
all
the
people
who
is
injured
is
mentioned.
We're
fine
people
might
actually
be
helpful
to
be
an
author
who
is
from
a
sort
of
more
light.
Trician
like
you
know
what
why
have
made
it
much
confidence
in
Martin
Thompson,
you
know
he's
obviously
from
the
sort
of
heavy
gift
tradition
is
that
might
be
I'll
follow
us
on
with
really
tradition
to
me.
You.
B
Yeah
Wow
yeah,
we
will
deal
with
that.
Martin
feel
free
to
submit
the
O
and
then
we'll
work
out
the
authorship
later
on.
I,
don't
think
it's
a
big
deal
so
I
guess.
On
that
note,
we
don't
really
have
anything
else
to
discuss
on
this
there's
more
pressing
issues
going
once
going
twice.
Alright,
we
will
adjourn
here
thanks.
Everyone.