►
From YouTube: IETF106-GIT-20191119-1520
Description
GIT meeting session at IETF106
2019/11/19 1520
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
They're
live
streaming
this
on
YouTube.
My
question
is:
why?
Well
because
I
was
told
to
so
I
think
it
was
because
they
were
live-streaming
the
last
one
and
they
just
decided.
C
E
E
This
is
the
note-
well
you've
probably
seen
this
several
times
before.
So,
if
you're
not
familiar
with,
if
we
take
a
look-
and
you
know,
try
to
abide
by
it
or
don't
try
do
some
administrative
things,
so
the
blue
sheets
are
going
around.
Please
fill
them
out.
If
bosses
are
yeah,
do
we
have
a
JavaScript
anyone
willing
to
volunteer.
E
B
A
Basically,
since
it's
not
clear,
everyone
normally
does
agendas
by
putting
draft
file
names.
The
first
two
things
here
are
the
two
drafts
in
the
working
group.
We
will
discuss
them
reasonably
briefly.
The
third
thing
is
actually
not
a
working
group
item.
It's
a
tutorial
that
people
have
been
putting
together
to
help
other
working
groups
sort
of
with
what
we've
done,
but
the
first
two
will
actually
probably
go
reasonably
quickly
and
that'll
leave
plenty
of
time
to
talk
about
the
tutorial.
If
people
have
been
reading
it
all.
E
Right
yeah,
so
with
that
we're
gonna
start
there's,
there
are
no
slides
for
that.
The
first
presentation,
which
is
the
github
configuration
document
from
Vaughn
Alyssa.
We
do
have,
however,
three
issues
that
it
would
be
great
if
we
could
just
march
through
them
and
do
something
with
them,
ideally
close
them
or
do
something
else.
So
to
that
end,
I'm
gonna
click
on
the
first
one
yeah.
This
was
brought
up
by
I
forget
exactly
who
on
the
list
well,
I.
Of
course,
I
filed
it.
E
F
G
F
F
E
F
F
This
is
Mark's
one
we
moved
marks
issue.
I
can
probably
speak
to
it
briefly.
A
lot
of
documents
have
a
brief
note
at
the
start
of
them.
That
explains
what
it
is
that
the
the
document
is
doing
where
to
discuss
it,
where
to
find
the
repository
where
to
file
issues
that
sort
of
thing
conveniently
I
recently
added
this
capability
to
the
template,
so
it
will
be
automatically
added
by
anyone
who's
using
a
modern
setup,
so
yay
another
one
that
solved,
but
we
can
probably
make
some
notes
about
that
as
well.
In.
H
E
I
Nottingham
I
really
don't
want
to
like
get
in
the
way
of
year,
I'm
shutting
down
this
working
group
party.
But
what's
the
delineation
between
these
documents?
Again
because
it
seems
like
it's
really
fuzzy
a
lot
of
the
time
it.
A
Is
but
so
the
document
were
that
we're
discussing
is
what
is
the
tooling,
that
the
ietf
should
be
doing
to
help
working
groups
use
github,
and
the
other
document
is
how
to
use
github,
especially
if
you're
not
using
tooling
such
as
you
may
want
to
add
this.
You
may
want
to
do
this
and
that's
why
I
had
suggested
this
actually
goes
in
the
other
dot
in
Martin's
document.
A
I
E
F
F
That
is
abstract
of
the
specifics
of
how
that's
that's
done
so
I
would
say
it
is.
It
is
useful
to
put
a
note
in
the
draft
pointing
to
where
the
repository
is,
but
I
wouldn't
specify
the
mechanics
of
that,
whereas
the
other
day,
the
other
draft
is
very
specifically
hey
tools.
Team.
We
want
to
link
in
the
data
tracker
that
points
to
these
repositories
all
similar,
so
I
I
think
it's
fairly
crisp
when
you
get
right
down
to
it,
but
I
do
agree
with
mark
that
maybe
it
would
have
been
better
in
retrospect.
F
I
You're
gonna
make
the
joke,
get
it
right,
I,
you
know
I.
Think
I
read
the
documents
relatively
recently.
Perhaps
you
can
improve
this
by
just
making
it
absolutely
crystal
clear
in
the
abstract
in
the
introduction
who
the
audience
for
the
document
is,
and
ideally
in
the
title
of
the
document
who
the
audience
of
the
document
is
because
I
didn't
get
that
sense
from
reading
them
yeah
great
suggestion.
You
certainly
do
that.
F
J
Yeah
hi
rich
sauce,
yeah
I,
just
added
the
comment.
Oh
let's
see
six
minutes
ago
we're
doing
some
work
in
the
data
tracker
to
normalize
all
of
the
links
or
like
additional
URLs
field
will
have
normalized
names
for
most
of
those
things,
so
you
can
like
sort
of
add
it
programmatically.
J
B
B
A
F
F
I
went
through
it
in
a
little
bit
of
detail
and
it
talks
primarily
about
the
process
by
which
the
ITF
decides
to
turn
internet
drafts
in
to
standards,
not
the
process
by
which
the
internet
drafts
get
hammered
out
in
the
working
group,
and
so
my
suggestion
is
that
we
don't
deal
with
basically
nine
at
all
in
in
this
particular
document.
Does
anyone
have
a
different
understanding
of
the
purpose
of
that
document
and
would
suggest
that
we
do
otherwise?
F
Okay
I
see
some
thumbs
up
the
next
one?
We
already
cite
vcp
25,
which
is
the
working
group
process
document
and
though
BCP
25
is
extraordinarily
high
level
relative
to
the
sort
of
thing
that
this
document
that
we're
talking
about
is.
There
are
some
aspects
of
this
that
we
we
already
address
very
now,
narrowly
targeted.
F
So
most
of
the
uses
that
we're
talking
about
here
relate
to
the
the
document
production
process.
I
know
that
there
are
some
other
aspects
of
BCP
25
that
people
use
github
to
assist
in
that
being,
primarily
things
like
session
planning
management
of
agendas
and
and
presentation
materials,
for
instance,
and
I-
know
that
a
lot
of
working
group
charters
end
up
on
github
and
get
beaten
out
on
that
one.
My
proposal,
which
I
wasn't
gonna,
merge,
but
then
Paul
did
it
for
me
violating
one
of
the
golden
rules
in
this
document.
F
Yeah
I
had
hope
to
discuss
it
here
before
I
merge.
That
was
that
only
documents
would
be
in
scope
and
I've
in
that
pull
request.
I
explicitly
said
that
this
is
only
documents,
though
these
other
things
can
be
used
now.
I
thought
that
Paul's
tacit
acceptance
of
that
indicates
that
I
was
not
entirely
crazy,
but
I'd
like
to
make
sure
that
people
in
this
room
also
think
that
I'm
not
entirely
crazy.
F
A
K
Yeah
this
is
Shawn
Turner,
just
to
observe
that
if
you
told
me
I
couldn't
do
it,
I
would
probably
ignore
that
advice
and
I
would
keep
right
on
doing
the
other.
The
other
things.
Oh,
it's.
G
F
K
F
Having
an
having
that
advice
and
applying
that
advice
to
the
save
the
development
of
the
chart
or
a
revision
to
the
Charter,
is
it
crazy?
People
are
going
to
do
that
and
it
turns
out
that
most
of
this
advice
is
still
applicable
in
that
context.
But
I
didn't
really
want
to
get
too
bound
up
in
dealing
with
that
problem.
In
fact
that
the
proposed
text
did
say
that
and
I
was
gonna
maybe
put
that
up
on
screen,
but
we
can
deal
with
that
and
working
group
last
call
okay.
F
Next,
oh
and
the
last
one
I
don't
know
who
open
this
issue,
but
there
was
a
point
raised
about
the
fact
that
github
does
occasionally
tend
to
attract
spam
and
and
misbehavior
of
various
forms.
There
are
moderation
tools,
but
they're
not
centralized
in
any
way
that
would
be
available
to
us.
So,
for
instance,
we
couldn't
if
we
wanted
the
equivalent
of
a
posting
rights
action
block
someone
across
all
of
the
different
organizations
that
the
ITF
would
use.
So
there's
some
limitations
there.
F
So
I
have
a
couple
of
questions
here
and
then
these
are
a
little
difficult
for
me
to
deal
with
here,
because
I
don't
know
whether
this
expands
the
scope
of
the
document
or
not.
So
a
like
a
bit
of
discussion
about
this
things
like
could
we
do?
We
need
to
have
rolls
around
things
like
dealing
with
someone
who's
misbehaving
on
github?
F
We
can
block
them
from
repositories.
Can
we
do
that
unilaterally
or
on
the
basis
that?
Well
maybe
they
can
just
go
to
the
mailing
list
and
and
take
the
complaints
there
or
do
we
have
to
have
these
repositories
in
the
and
and
all
the
things
associated
with
an
operate
under
rules
that
are
similar
to
the
mailing
lists
themselves
and
to
what
extent
do
we
need
to
support
the
whatever
actions
that
we
we
take
in?
In
that
word,
tooling,
and
and
whatnot.
G
K
On
Turner
again
so
I
would
I
would
like
to
know
that
in
my
you
know
three
years,
I
guess
of
using
github
or
something
like
that.
Something
call
me
out
on
how
long
that
I
find
that
there's
a
whole
lot
less
times
where
I
felt
like
there
was
any
kind
of
bad
behavior
that
raised
any
kind
of
the
level
of
the
bad
behavior
that
I've
seen
on
recent
mailing
lists
in
the
IETF.
So
maybe
we
just
let
this
go
because
it's
just
not
there
and
we're
trying
to
solve
a
problem
that
doesn't
really
exist.
K
F
I'm
comfortable
with
that
that
answer
anyone
else,
this
is
Barry
leave
I'm
comfortable
with
that
answer.
Also,
I
think
what
makes
sense
is
to
yes
treat.
Github
is
a
mailing
list,
not
for
the
purposes
of
PR
action
for
the
purposes
of
abuse
mitigation
in
general
and
just
whatever
you
can
do
with
a
mailing
list,
you're
allowed
to
do
with
github
and
just
leave
it
at
that.
We
need
to
say
nothing
more.
J
A
F
I'm
I
think
the
conclusion
here
would
be
that
we
don't
put
anything
in
this
draft
on
this
on
this
topic
and
we
deal
with
using
the
the
existing
support
infrastructure
that
we
have
I
think
that's
that's
a
pretty
sensation
because
based
heavily
on
people
so
which
is
based
heavily
on
people-
and
this
is
a
people
problem
and
like
Sean
said
this
is
not
a
problem.
That's
really
been
a
major
problem
in
the
past.
It
was
worse
in
the
case
that
I
identified
at
the
w3c
and
it
required
a
little
more
process
than
I.
F
E
F
E
E
Shortly,
thank
you
all
right.
So
yeah
we're
basically
at
a
point
now,
where
both
documents
are
fairly
stable
and
mature,
ready
to
move
forward.
At
least
the
chairs
think
so
so
we'd
like
to
start
working
group
last
call
for
both
of
them
right
after
this
meeting
ends
and
we
get
Martin's
updated
version.
Are
there
any
objections
to
that
great
I?
Guess
that
that
would
go
back
over
to
the
tutorial
so
another
thing
that
we've
been
working
on
sort
of
inside?
E
This
is
not
you
know
a
working
group
deliverable
by
any
means
it's
just
something
that
we
kind
of
put
together
to
help
people
not
familiar
with
github
or
get
in
general
and
who
might
want
to
start
using
it
to
better
contribute
to
working
groups,
so
it
as
the
title
suggests,
workflow
or
a
you
know
tutorial
for
kind
of
getting
used
to
these
new
technologies.
What
the
terms
mean,
what
the
typical
workflows
are
like
the
link
I
should
a
link,
but
you
can
find
it
on
the
github
repo
or
page
for
this
working
group.
E
E
E
If
so,
perhaps
I
don't
know,
let
us
know
at
the
mic
or
on
the
mailing
list
there
is.
There
are
suggestions
for
things
and
tools
that
might
be
useful
in
one
of
the
wiki
pages
should
have
brought
the
link
up.
Actually,
I
could
do
that
right
now
on
speaking
to
it
and
if
folks
feel
so
inclined
in
doing
some
of
these
things
or
commenting
on
them,
that
would
be
lovely,
but
again
none
of
this
is
required.
E
A
A
If
people
have
ideas
for
what
they
would
want
to
see
in
a
recharter
of
the
working
group
or
additional
work,
we
can
sort
of
have
that
discussion
as
well
at
the
same
time,
because
that
might
even
tie
into
the
two
documents
or
one
of
the
two
documents,
but
barring
that
or
barring
agreement,
that
we
should
do
that.
Then
post
working
group
last
call
we
would
send
them
on
to
our
glorious
ad
and
the
working
group
would
stay
up
through
the
deliberation
of
the
isg
and
then
probably
close
down.
A
Mailing
list
will
stay
up
because
it
has
a
cute
name,
it's
quite
attractive
to
people
who
have
problems
related
to
this
mailing.
This
could
absolutely
be
used
for
other
things
such
as
talking
about
the
tooling
talking
about
the
tutorial
and
things
like
that.
But
the
working
group,
in
my
mind,
is
likely
to
shut
down
before
the
next
IETF
meeting,
assuming
the
ISG
moves,
these
things
through
at
sort
of
the
normal
pace.