►
From YouTube: IETF102-WGCHAIRS-20180718-1215
Description
WGCHAIRS meeting session at IETF102
2018/07/18 1215
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
C
D
E
C
C
So
one
of
the
things
I
wanted
yeah
a
lot
of
people,
if
you're
not
already
using
it,
and
you
don't
intend
to.
Perhaps
this
might
change
your
minds
I'm,
not
actually
looking
to
change
minds
at
this
point.
I
think
that
one
has
sailed.
One
of
the
things
I
wanted
to
talk
about
was
the
the
rationale
for
doing
this.
People
often
talk
about
well.
Why
don't
we
use
SPN
or
gitlab
or
what?
Why
doesn't
the
idea?
C
F
C
C
Don't
think
that
some
of
the
efforts
that
at
least
I've
been
involved
in
would
have
been
anywhere
near
as
successful
if
it
weren't
for
that
getting
involved
one
if
we
go
forward.
You
know
this
is
current.
This
is
getting
truncated
carried,
you
know,
can
you
hit
the
fit
to
page
think
it's
it's
unfortunate.
I've
I
picked
up
the
habit
of
going
four
by
three
and
this
just
go.
Fullscreen
I,
don't
know
what's
going
on,
but
it's
been
cut.
C
C
C
They
exist
and
they're
all
integrated
together,
which
is
kind
of
handy
next.
You
get
a
nice
long
list
of
issues
and
you
can
tag
them
and
wonderful
things
like
that.
If
anyone
picks
up
this
slide
deck,
all
of
these
things
actually
link
all
the
pictures
link
to
the
to
the
page,
that's
being
shown
and
second
tool
around
yourself,
I
decided.
We
didn't
have
time
for
that.
Next.
C
One
of
the
nice
things
here
is
that
the
issues
are
effectively
threaded
discussions
and
I've
heard
a
few
people
comment
that
this
is
a
little
bit
difficult
to
manage
I'll
get
into
more
of
that
later,
but
each
one
of
these
issues
has
a
discussion
associated
with
it,
which
is
the
way
that
some
people
are
used
to
engaging
in
these
sort
of
conversations.
So
you've
got
to
watch
some
traps
there.
Next,
please
pull
requests
similar
the
list
of
them
pick
out
at
the
next
page.
C
There
is
some
code
review
and
this
uses
a
standard
sort
of
diff
display,
and
people
can
attach
comments
to
individual
change,
changes
in
the
in
the
proposed
change
and
make
comments
and
have
discussions
and
other
wonderful
things
as
well.
Next,
one
of
the
nice
things
here
is
that
every
single
change
is
enters
a
log.
It's
all
visible!
You
can
go
back
through
that
history.
You
can
see
why
the
changes
were
made.
C
You
can
link
those
changes
up
to
the
issues
that
that
drove
those
changes
and
that's
nice,
and
it's
also
good
as
an
editor,
to
be
able
to
get
rapid
feedback
on
these
things.
So
you
make
a
change
that
changes
it
immediately
visible
and
people
will
look
at
the
that
change
and
be
able
to
comment
on
that
immediately.
One
of
the
things
who
have
noticed
is
that,
particularly
with
the
working
groups
I'm
involved
with,
we
maintain
an
editor's
copy
and
that's
where
people
go
now
to
to
make
comments,
and
so
we
don't
have
this.
C
This
problem
of
people
coming
and
discussing
the
changes
that
were
in
the
latest
draft
that
have
been
since
superseded
by
the
conversation
moving
on
changes
having
been
made
in
the
editors
copy
and
not
having
a
common
shared
view
of
what
things
are
at
now.
That
leads
to
a
problem
in
that
there's
potential
confusion
between
the
two
of
these
things,
but
generally
I've
found
that
it's
relatively
easy
to
manage
those
sort
of
thing,
particularly
for
those
people
who
are
intimately
involved
in
the
process.
C
So
we
maintain
a
copy
of
the
document.
So
the
question
was:
what
do
you
mean
by
an
editor's
copy?
We
maintain
a
copy
of
the
rendered
document,
so
HTML
page
that
contains
the
text
of
the
latest
changes
that
were
made
so
the
live
copy,
as
as
it
were.
So
if
someone
comes
in
with
a
comment
and
we
make
a
change
that
changes
immediately
immediately
reflected
in
their
copy
I'll
go
I'll,
go
into
that
some
more
later.
C
This
and
some
things
I'd
like
to
show
next,
please,
as
I
said
before,
there's
a
massive
community
of
people
on
this
website.
That's
millions
and
millions.
It's
it's
kind
of
absurd!
What's
nice
about
that,
is
that
the
that
large
community
are
all
familiar
with
the
tools,
and
so
that
makes
it
much
more
accessible
for
communication
next,
all
right.
So
this
is
the
problem
part.
C
So
one
of
the
policies
that
we
started
out
with
in
some
of
these
efforts
here
is
probably
the
simplest
one,
which
is
that,
if
discussion
starts
to
sprout
up
all
over
github,
you
stomp
on
it
pretty
hard
and
say
we
have
a
working
group
mailing
list.
Please
use
that
feel.
Free
to
use
github
to
discuss
editorial
things,
knits
typos
the
things
that
are
appropriate
for
that
sort
of
thing.
C
H
That
sounds
like
a
very
effective
way
to
handle
controversy.
There's
another
kind
of
discussion
which
is
to
socialize
important
decisions,
and
it's
like
in
quick.
There
was
a
bunch
of
topics
that
were
raised.
They
have
some
discussion
on
them.
Would
you
drive
those
to
the
mailing
list
as
well
and
then
how
do
you
know.
I
I'm
about
to
add
into
this
okay
I'm
yeah,
Thomas
Martin.
Is
that
really
true
what
you
said
like
when
I
when
I
look
at
the
tls
discussion,
so
even
things
that
we
talked
about
yesterday
on
quick
if
some
of
the
design
decisions
on
and
exxon,
for
example,
the
connection
ID,
the
response
that
you
gave
me?
Oh
it's
somewhere
on
github,
so
previously
the
barrier
of
entry
for
someone
making
discussions
and
contribution
the
question.
J
C
Eventually,
people
learn,
and,
and
so
what
happens
is
after
a
little
while
as
the
as
the
chairs
of
careful
to
sort
of
nudge.
The
conversation
background
on
to
the
into
the
places
that
they'd
like
to
have
it
people,
learn
and
start
helping
you
nudge
it
themselves
and
so
that
it
actually
accelerates
this.
It's
it
works
out
pretty
well,
it
meant.
K
We
looked
at
audit
taking
the
knowledge
notifications
that
are
automatically
generated
as
discussions
go
on
and
echoing
them
to
a
list.
We
did
that
sort
of
an
offline
discussion
and
we
we
did
it
to
a
chairs
page,
just
as
a
chairs
alias
just
as
a
test,
and
it's
just
like
way
too
verbose.
I
mean
it's
just
like
way
too
chatty
to
do
it
to
the
actual
list.
If
you
want
to
do
it
to
the
working
group
list,
you
can,
but
you
know
I,
think
you're,
saying
some.
C
Actually
raises
a
point
that
I'm
not
covering
my
slides
and
I,
probably
should
talk
about.
The
w3c
has
been
using
github
for
a
long
time
and
probably
in
in
a
far
more
advanced
mode
than
than
anything,
we're
talking
about
here
and
they've
developed
a
tool
which
will
reflect
certain
activity
from
github
on
to
a
mailing
list,
and
you
can
tune
what
it,
what
a
echoes
and
where
we
currently
have
I
think
it's
a
weekly
synopsis
of
the
things
that
have
happened
being
echoed
into
the
into
the
quick
working
group
mailing
list.
C
We
also
have
a
separate
mailing
list
that
is
the
firehose
and
I.
Don't
believe
anyone
subscribes
to
that
one
because
it
is
simply
unmanageable.
One
of
the
nice
things
about
github
is
that
it
gives
you
a
lot
of
tools
to
manage
how
notifications
come
in
and
you
don't
get
that
with
the
firehose.
So
that's
something
to
keep
in
mind.
C
There's
there's
a
tool,
that's
used,
you
have
to
install
it
and
run
it
on
some
server
somewhere,
but
it's
effectively
automatically
runs
and
generates
the
summary
of
saying
the
following
issues
were
open.
The
following
issues
were
closed.
They
were
discussion
on
the
following
issues:
that
sort
of
thing
Alice
I
can
dig
it
up
and
pass
it
on.
If
people
are
interested.
I
Not
a
question
I,
don't
know
if
you
will
talk
about
this,
but
I
noticed
that
throughout
different
working
groups
they
use
the
process
for
github
usage
on
a
different
documents
is
very
different.
Some
even
within
a
group
there
may
be
different
repositories
for
different
documents
and
and
makes
it
very
difficult
to
jump.
I
L
C
L
Just
one
comment
which
is
I'm,
hoping
that
at
one
point
you
will
get
to
what
your
recommendations
are,
particularly
with
respect,
because
a
lot
of
these
things
can
be
managed
that
by
development
of
tools
to
be
much
better
than
it
is
today
and
I
would
even
characterize
the
WC
approaches
like
a
to
Wed,
hawk
I,
think
yeah.
So
yeah
your
recommendations
would
be
very
much.
C
If
there's
some
recommendations
further
on
I'm,
not
sure
that
there's
going
to
be
comprehensive,
but
we
can
continue
that
discussion
next,
so
a
number
of
working
groups
have
sort
of
migrated
to
what
I
think
of
as
a
more
sort
of
natural
discussion
approach
and
quicks
certainly
taken
this
approach.
Hdb's
doing
the
same,
you
essentially
permit
discussion
on
github.
C
It's
always
been
the
case.
We
take
the
big
stuff
to
mailing
group
to
mailing
lists
and
and
make
sure
that
anything
like
that
has
far-reaching
implications.
It's
that
broader
audience,
one
of
the
problems
has
discussed
was
that
you
often
don't
reach
the
entire
working
group
when
you,
when
you
do
this,
and
so
this
has
worked
out
reasonably
well
and
quick.
It
means
that
you
have
all
of
this.
The
discussion
related
to
a
given
issue
in
the
same
place.
It's
a
different
way
of
working,
so
it
may
be.
C
C
We
actually,
we
actually
had
one
of
the
pull
requests
reached
the
limits
of
the
capabilities
of
the
server,
and
it
would
time
out
when
you
were
true
that
the
back
end
would
timeout
and
you
will
get
a
nice
picture
of
a
unicorn
and
no
content,
so
be
a
little
bit
careful
with
that
one
next,
so
My
Chem
recommendation
here
is
that
as
Bernard
pointed
out
it
would.
It
is
a
little
bit
ad
hoc
in
terms
of
the
process.
C
I,
don't
think
that's
entirely
a
problematic,
but
there's
a
couple
of
guidelines
that
that
are
important
here,
I
think
it's
very
important
that
the
working
group
is
involved
in
the
decision
to
to
set
the
policy
here.
If
the
working
group
is
not
comfortable
with
the
way
that
you're
working,
then
that's
not
going
to
be
good.
So
what
I've
done
and
what
other
groups
have
worked
in
have
done
has
been
to
send
an
email
to
the
working
group.
C
C
The
nice
thing
is
that
github
will
show
you
a
little
notice,
like
you
can
see
on
the
top
there
and
that
notice
is
shown
to
anyone
who
starts
contributing
to
the
to
the
group.
So
someone
wants
to
open
an
issue.
They
see
this
little
notice
and
they're
they're
encouraged
to
go
and
read
the
guidelines.
Of
course,
the
quick
guidelines
are
enormous,
which
has
all
of
the
problems
associated
with
that,
but
I
think
this
is
kind
of
the
best
that
we
that
we
have
right
now
and
anyone
who's
doing.
C
This
I
think
this
is
kind
of
the
baseline
requirements
for
getting
something
set
up.
There's
relatively
straightforward
to
do
it's
just
that.
You
you
have
to
spend
the
time
just
to
set
things
up
next,
okay,
so
I'm
going
to
be
even
more
opinionated
here
in
in
what
I
think
the
established
best
practices
are.
You
may
find
you
disagree
with
me.
That's
fine!
It's
okay!
To
be
wrong!.
C
But
I'll
explain
why
I
think
each
one
of
those
things
is
is
is
useful
and
hopefully,
through
a
little
bit
more
detail
about
what
sort
of
things
we
got
here
next
place.
So
the
accepted
model
here
and
the
one
that's
been
tends
to
be
used
is
that
you
have
a
working
group
and
for
that
working
group
you
create
an
organization.
This
is
essentially
github
way
of
making
a
team,
and
what
we
have
here
is
an
example.
C
We
have
the
chairs
who
owned
this
group.
We
have
an
area
director
who
owns
this
group
responsible
area
director
owns
the
group,
and
then
we
have
the
various
document,
editors
also
in
the
organization,
and
we
have
a
number
of
repositories
under
that
organization.
It's
generally,
what
you
will
find
is
that
individual
drafts
will
be
under
individual
users,
but
once
they
migrate
to
being
ITF
drafts,
it's
good
to
have
them
moved
into
this
sort
of
organization,
so
that
you
have
that's
that
central
place
to
go.
C
That's
this
is
the
practice
that
most
working
groups
that
I've
been
involved
with
have
used.
Other
people
have
suggested
other
models,
but
this
ones
need
to
be
working
recently.
Well
next,
so,
as
I
said
chairs
what
the
responsible
ID
on
the
organization,
that
means
they
have
the
ability
to
set
policies
and
all
those
sorts
of
things
they
have
administrative
privileges,
essentially
generally
I,
recommend
that
separate
work
items
get
separate
repositories.
C
One
of
the
things
one
of
the
I
think
a
mistake
that
we
made
in
the
HTTP
working
group
is
to
lump
all
of
the
work
into
the
one
repository.
That
means
that
you
have
a
group
of
north
of
15,
plus
editors,
all
working
on
the
same
repository,
it's
a
little
clumsy,
particularly
when
it
comes
to
issue
tracking,
because
now
you
have
15
disparate
drafts,
all
in
the
same
issue
tracker
and
the
tools
aren't
that
great.
C
And
I
think
it's
fine
thing
to
do.
Yes,
yes,
chairs,
do
not
touch
one
draft.
The
repository
is
the
easiest
thing
to
do,
but
sometimes
it's
necessary
to
have
multiple
drafts
together,
because
they're
interrelated
text
moves
between
them
back
and
forth,
and
if
you
find
that
you,
if
you
think
that
you
might
be
doing
that
sort
of
thing,
then
you
probably
want
them
in
the
same
repository.
Quick
is
doing
that
and
it's
awful
but
necessary.
C
K
On
the
prior
one,
about
adding
secretary
comment
about
adding
Secretariat
I,
think
that
should
be
discussed
with
the
secretary
before
we
make
a
policy
or
even
make
it
a
recommendation
because
there's
a
cost
associated
with
it,
so
how
there
are
not
volunteers.
So
if
suddenly
we're
putting
an
additional
burden
on
the
Secretariat,
you
know
we
should
make
sure
that
that's
understood
with
what
the
cost
of
that
is,
and
you
know,
there's
an
agreement
that
we
should
be
spending
money
on
them.
Well,.
K
C
N
C
So
this
is
one
thing:
I
didn't
cover,
okay,
so
one
of
the
things
that
one
of
the
things
that
quick
is
doing
is
making
a
team
of
people
who
don't
have
any
right
privileges,
and
that
makes
up
a
little
bit
easier
to
find
those
people
to
assign
reviews
to,
and
mention
and
things
like
that.
So
that's
what
we're
doing
there!
It's
completely
optional!
There's
no
there's
no
requirement
to
be
part
of
the
organization
in
order
a
comment
or
review
or
create
issues
or
anything
like
that.
There
are
they.
C
C
C
C
It's
yeah.
It's
also
much
much
easier
to
users,
as
pointed
out
so
issue
management
at
some
point.
You're
going
to
want
to
do
some
of
this,
and
it's
very
useful
to
be
able
to
distinguish
between
stuff
that
the
working
group
needs
to
discuss
and
stuff
that
the
editors
put
on
the
pile
just
for
their
own
benefit.
Typos.
G
C
C
C
That
does
not
count
the
fact
that
there
was
I
think
a
1,700
of
them
closed.
So
it's
it
can
get
a
little
bit
tiresome
and
there
are.
There
are
other
tools
here
like
milestones
and
the
project
board,
and
there
are
third-party
add-on,
so
you
can
use.
It
depends
on
how
far
you
want
to
get
into
that
I
find
that
for
single
draft
repositories
simply
separating
those
issues
that
need
discussion
from
those
issues.
That
don't
is
is
all
you
really
need
to
do.
A
lot
of
drafts
that
I've
seen
have
a
handful
at
five.
G
C
C
I'm
into
so,
the
policy
we've
adopted
in
the
groups
that
I'm
working
in
is
that
the
issues
are
there
primarily
for
the
benefit
of
the
editors,
and
so
the
editors
will
maintain
the
issue
in
the
open
state
until
such
time
as
they
think
they
have
fixed
the
problem.
Creek
has
a
process
that
I
think
is
reasonably
good
in
this
regard.
In
that
any
issue
that
is
tagged,
design
and
is
closed.
C
We
would
like
to
confirm
that
that
there
is
consensus
on
these
things
like
a
mini
last
call
on
those
things
and,
and
that
allows
us
to
collect
that
sort
of
final
feedback
on
those
things
and
now
they'll
actually
tag
those
things
once
that
that
process
has
been
completed
and
that's
probably
necessary,
given
the
sort
of
nature
of
the
discussion
there,
that's
something
that
I
think
the
the
chairs
will
have
to
work
out.
It's
usually
part
of
contributing
policy.
C
B
So
Dave
Taylor,
so
I
chair
the
chief
working
group,
which
plans
to
start
using
this
so
I'm
part
of
your
core
audience,
we're
not
using
it
yet
and
I'm
here
to
learn
how
to
use
it
in
the
way
that
the
IETF
commonly
we
want
to
use
things.
My
question
is
about
the
design
label,
is
that
they
github
concept
or
is
that
something
that
every
working
group
creates
a
label
and
designed
as
a
convention
is
designed
the
same
thing
as
technical
or
is
there
a
distinction
between
design
and
technical?
Is
this
a
convention
you're
saying
it's.
B
C
O
B
O
C
P
Sorry,
Tommy
yeah,
so
I
think
we
have
an
opportunity
for
some
of
our
other
groups
to
try
to
conform
more
to
that,
for
example,
instead
of
design
we
use
discuss
which
I
think
it's
more
like,
you
should
do
this
as
opposed
to
we've
done
design
and
it
administrative
but
I,
think
aligning
would
make
sense.
Yeah.
C
C
C
R
C
G
C
Did
that
go
on
so
we
haven't.
This.
Is
the
quick
read
me
it's
a
little
bit
out
of
date,
you'll
notice
here
that
the
the
draft
we
have
there's
a
section
for
each
one
of
them,
and
there
are
three
links
there
and
the
first
one
of
those
links,
links
to
the
editors
copy
of
the
document.
I
think
it's
on
the
next
page.
C
F
C
Now
I
think
we
got
it
down
to
that
point
for
the
whole
thing
to
go
through,
and
so
that's
a
nice
property.
If
you
manage
to
screw
up
your
commits
and
break
the
draft,
which
is
surprisingly
easy,
it
will
send
you
an
email
and
you
get
to
fix
it.
We
use
we
use
this
for
pull
requests
to
check
that
the
pull
request
is
syntactically
valid.
So
it
will
report
on
that
and
on
the
pull
requests
now.
O
C
Is
there
are
detailed?
Instructions
were
coming
to
bed
I.
Think
next,
please
one
of
the
things
this
maintains
is
a
page
that
shows
all
of
the
different
documents,
and
so
you
can
get
access
to
the
plain
text
version
of
the
draft,
the
HTML
version
of
the
draft
diffs
and
various
other
things
like
that.
There's
there's
a
bunch
of
other
things.
Someone
mentioned
archival.
C
This
is
your
archive
right
here,
and
so
all
of
this
is
actually
maintained
on
a
separate
branch
in
the
repository
and
one
of
the
things
that
this
tool
chain
managers
is,
it
saves
a
copy
of
all
the
issues
and
pull
requests
into
the
repository
every
time
it
does
this,
and
so
there's
a
little
link
there
that
actually
the
you
can
look
at
the
saved
issues
and
scroll
through
them
and
that's
actually
something
that
works
offline
as
well.
You
can
switch
to
that
branch.
C
You
can
the
the
last
submission
to
the
ITF,
so
it
actually
goes
off
to
the
data
tracker
and
looks
at
the
last
version,
you'll
notice
here
that
it
also
shows
previews
for
different
branches.
So
if,
if
you
have
editors
working
on
a
draft
and
they're
working
on
different
branches
for
different
changes,
you
can
actually
get
a
preview
of
those
changes
right
here
as
well,
and
so
all
of
that
information
is
right
there.
C
It's
really
useful,
particularly
as
an
editor
when
you
to
present
a
big
change
in
front
of
someone
you
this
automatically
gets
generated
when
you
push
one
of
these
branches
up
there,
and
so
you
can
say,
oh
and
by
the
way,
if
you
want
to
have
a
look
at
this
is
the
link
and
you
can
review
that
you
can
always
look
at
the
bull
request.
That's
been
generated
and
go
through
the
actual
code
changes,
but
it's
sometimes
nice
to
be
able
to
have
a
look
at
the
draft
and
go
through
that
in
detail.
C
C
It's
got
simple
commands
for
building
the
changes,
which
is
kind
of
handy.
It
integrates
with
the
continuous
integration
thing
for
validates
the
changes
and
generates
these
previews
and
and
saves
all
the
issues
into
the
repository,
and
does
all
of
that.
One
of
the
things
that
continuous
integration
allows
us
to
do
is
automated
submission.
So
one
of
the
multi
moving
part
processes
in
all
of
this
is
submitting
a
draft
to
the
tracker
in
in
this
case
it
supports
a
mode
where
you
tag.
C
You
create
a
tag
with
the
draft
name,
a
number
that
you
would
like
to
have
created
and
you
push
that
tag
up
into
github
and
continuous
integration
will
submit
it
to
the
data
tracker,
for
you
does
all
that
automatically,
and
that
means
that
your
repository
now
has
a
tag
that
identifies
the
the
state
of
the
repository
when
you
generated
their
draft
and
it
matches
up
perfectly
at
that
point.
It
also
does
things
like
produced
ifs
and
and,
and
that
doesn't
even
make
sense,
but
it
manages
issue
status
and
things
like
that
custom.
C
C
One
of
the
things
you
can
do
and
I
didn't
I'm,
not
actually
I,
don't
think
we
had
time
to
go
through,
but
the
contribution
process
via
github
itself
is.
You
can
just
go
to
the
web
page.
There's
an
edit
button
on
the
on
the
page,
I
think.
If
we
go
back
about
ten
slides
this,
if
there's
the
picture
of
the
XML
there's
a
button,
there
there's
a
little
pencil
button
in
the
top
corner.
C
C
C
C
Can
the
editors
use
this
offline
disposal
reasonably
well
offline,
the
if
you're
using
cramdown,
for
instance,
it
maintains
a
cache
of
all
the
references
that
you
have.
If
you
maintaining
it
your
own
copy
of
the
bib
XML
stuff
you
can,
you
can
actually
do
a
ton
of
work
that
way.
Unfortunately,
if
you
want
to
add
a
new
reference,
is
a
little
bit
tricky
because
that's
that's
hard,
there's
there's
some
options
in
the
cramdown
tool.
It'll,
look
like
you
work
offline
anyway,
but
then
kind.
F
C
T
T
C
Yeah
good
question
that
did
that
differs
between
the
authoring
tools.
I
think
in
mark
has
a
different
process
to
how
cramdown
might
manage
that
as
well,
and
that's
probably
something
more
further
than
those
people
one
of
the
nice
things
about
this
is
you
can
put
the
code
right
next
to
the
the
text
and
a
couple.
The
drafts
I
have
have
sample
code
and
they
do
that,
but
ultimately
I
I
think
I've
ended
up
copying
and
pasting
the
code
into
the
draft
as
necessary.
C
O
J
C
And
so
that
would
be.
That
would
be
possible
one
of
the
nice
things
with
with
doing
something
like
that,
is
that
if
you're,
if
you,
you
have
an
automatic
validation
process,
you
can
integrate
that
into
the
into
the
checking
of
the
draft,
and
so
when,
if
you're,
using
a
continuous
integration
system,
you
get
reports
on
whether
your
yang
is
valid,
which
I
think
is
a
pretty
useful
thing.
So.
O
C
So
one
of
the
things
that
I've
done
is
there's
a
draft
in
TLS
that
I
have
that
generates.
Example,
messages
and
that's
all
actually
generated
in
CI
the
entire
draft,
although
all
the
test
vectors,
otherwise
I,
wouldn't
be
unable
to
do
it.
It's
it's
50
60
pages
of
hex,
so
I'm
not
doing
that
next
I
think
that's
right!
Yeah!
We're
not
gonna
have
that
time.
For
that,
so
that's
more
information
I
did
publish
it
drops
a
little
while
ago,
I'm
like
sort
of
go
through
some
of
this
stuff.
There's
a
link
to
that.
S
S
C
U
C
C
C
Does
this
and
we
could
host
our
own,
but
we
lose
all
the
benefits
that
we're
looking
for,
because,
frankly,
a
lot
of
these
tools,
not
very
good,
apart
from
the
fact
that
they
had
the
community,
that's
there
and,
of
course,
we'd
also
lose
the
continuous
integration
stuff
unless
we
built
our
own
and
some
of
those
other
things
sort
of
flow.
On
from
that
video.
H
H
J
C
V
So
then
the
next
logical
thing
is
I
want
to
use
this.
It
sounds
amazing
right
now,
a
lot
of
my
draft
authors,
kind
of
run
their
own
repo
and
I
want
to
encourage.
This
is
a
better
way
to
collaborate
to
get
more
people
to
contribute
to
our
documents.
But,
right
now
these
repos
don't
have
a
readme,
don't
have
a
contributing,
no
mention
of
the
note
well
anywhere,
and
that
kind
of
worries
me
because
I
think
that
should
should
be
there,
like
you
discussed
these
working
groups
have
has
those
do.
V
C
Little
a
while
ago,
and
that's
the
discussion
a
little
while
ago
about
what
we
needed
to
do
and
I
believe
the
isg
did
actually
consult
the
lawyer
and
produce
some
text
this
tool
here,
if
the
tool
that
I
maintain
actually
contains
that
text,
and
so
if
you
use
it,
there's
a
set
up
process
that
will
generated
readme.
That
looks
very
much
like
the
quick
one
that
you
saw
there.
It
generates
a
contributing
thing:
it
I
don't
think
it
has.
It
has
a
license
as
well
that
points
to
the
to
the
right
place.
C
O
In
Cosmo
and
I
have
two
minor
points.
One
thing
as
a
regular
chair
you
may
want
to
do
is
actually
pull
in
drafts
that
have
not
yet
working
group
drafts
to
the
working
groups
repository.
So
you
don't
have
this.
Usually
the
adoption
is
something
where
a
lot
of
other
things
happen
and
so
on.
You
don't
want
this
to
be
the
time
when
the
author's
getting
familiar
with
how
to
use
the
regular
repository.
So
we
pull
in
stuff
early.
We
try
to
make
sure
the
readme
says
this
is
still
an
individual
submission,
but
it's
really
useful.
O
The
other
thing
I
wanted
to
quickly
comment
on
the
issue.
What
happens
if
the
new
owner
of
github
decides
to
destroy
it?
I
think
we
have
to
be
aware
that
this
is
very
much
a
possibility,
but
I
am
relatively
yea
happy
about
the
current
situation,
because
I
know
there
is
an
alternative.
It's
not
as
good.
It
doesn't
have
the
crown's
yet,
but
there
is
something
called
git
lab,
which
is
good
enough.
I
mean
it's
not
great,
but
it's
good
enough.
We
use
it
for
bitbucket
is
another
competitor.
O
C
And
so
part
of
the
part
of
the
reason
that
I
copy
issue
status
into
the
repository
is
so
that
at
least
we
don't
lose
the
topics,
it
doesn't
copy
everything
in
there
because
that's
a
massive
amount
of
information,
but
it
copies
issues
thanks
and
if
github
went
away
tomorrow,
all
the
editors
would
have
a
copy
of
all
the
code,
all
of
the
history,
all
of
the
issues
and
you'd
have
multiple
copies
of
that
anyway.
So
we've
got
a
pretty
good
backup
strategy
as
well.
A.
N
Sealant
I,
just
you
know,
I
we're
not
using
this,
but
we're
using
a
lot
of
individual
repositories
and
I.
Just
I
heard
something
that
you'd
have
you'd
change
when
you,
when
the
draft
change
from
non-working
group
to
work,
Europe
I
think
it'd
be
better
just
to
have
a
generic
name
for
it.
They
did
for
both
types
and
just
from
maintain
the
continuity
across
the
have
one
repository
per
draft
and
and
and
just
name
it
without
anything
that
would
imply
working
group
or
not.
P
A
A
H
Hi
Aaron
Falk.
So
to
recap
the
message
I
sent
out
to
the
working
of
chairs
list
earlier
I.
Think
most
of
you
know
that
I'm
running
a
lightning
talk
series
on
Sunday
evenings
called
Han
RFC,
and
the
idea
is
to
have
a
very
low
bar
of
submission
for
people
who
want
to
talk
about
an
idea
and
find
folks
who
want
to
collaborate
on
it.
H
H
My
sense
is
that
or
my
experience
is
that
occasionally
random
stuff
shows
up
in
working
groups
by
people
have
new
drafts
and
they're
trying
to
find
a
taker
for
it
and
they
especially
people
who
come
from
outside
the
IETF.
They
don't
really
know
where
to
go.
This
is
a
good
place
to
help
those
people
find
their
community,
especially
if
they
don't
know
what
area
or
they're.
You
know
it's
too
broad.
It's
helped
them
meet
folks
who
understand
the
ITF.
It
can
give
them
some
direction.
So
I
I'm
here
to
ask
for
your
help.
H
If
you
see
an
opportunity
like
that,
whether
it's
on
the
ITF
list
or
in
your
working
group,
you
can
send
them
to
you.
Just
direct
them
to
me
and
I'll
can
I've
been
doing
a
page,
a
different
page
for
each
ITF,
but
I'm
I
think
we
may.
We
may
just
come
up
with
a
standing
thing
at
some
point,
but
you
get
four
minutes
and-
and
you
talk
to
you
know
probably
100
150,
maybe
200
ITF
errs.
So
it's
the
idea,
it's
it
can
be.
You
know,
pre
draft.
H
H
The
problem
is
that
nobody
reads
the
ITF
list
anymore
and
so
we've
become
kind
of
fragmented
into
a
you
know
our
little
sub
lists,
and
so,
if
you
want
to
try
to
reach
a
bunch
of
people,
one
of
the
challenges
that
I've
been
having
is
trying
to.
Let
people
be
aware
of
this,
so
please
tell
folks
about
it.
If
you
think
something's
got
some
questions
on
it,
you
can
just
send
them
directly
to
me.
There's
if
you
go
to
the.
A
V
Everyone
I'm
David
Skinner's,
a
chair
of
DNS
service
discovery.
My
co-chair
Tim
Chang
is
stepping
down,
so
he's
been
absolutely
amazing
for
many
years,
but
I
am
looking
for
a
new
co-chair.
So
if
someone
in
the
room
wants
in
second
working
group
or
know
someone
that
could
be
a
good
fit,
please
reach
out
to
me,
we
haven't
found
a
replacement
yet
Thanks.
A
System
this
time,
there's
just
so
many
things
that
you
register
for,
and
it
turns
out
that
I
guess
some
of
you
think
we
should
so
we'll
take
it
to
the
list.
Ask
if,
if
there's
a
better
way
of
doing
this,
so
when
Lantry
ran
out
of
vegetarian
non-vegetarian,
okay,
so
maybe
we
need,
maybe
we
still
need
to
do
it
and
so,
in
any
event,
take
your
garbage.
Thank
you
comment
on
the
list.