►
From YouTube: IETF98-WUGH-20170327-1710
Description
WUGH meeting session at IETF98
2017/03/27 1710
A
B
A
So
here's
the
agenda
I'm
going
to
give
a
brief
overview,
which
is
what
I'm
doing
now
I'm
going
to
go
through
a
roll
call
of
I'm.
Oh
that's
right:
I
keep
forgetting,
or
in
Chicago
I'm
going
to
do
a
roll
call
of
that
I've
already
collected
and
I'm
going
to
zip
through
it
really
really
quickly.
You'll
see
why
once
I
get
there.
A
No
one
has
given
me
some
any
presentations
on
issue,
so
it'll
mostly
be
what
we
would
normally
call
a
mic
line
and
we'll
be
out
of
here
at
ten
minutes
after
six
and
we'll
have
much
more
to
talk
about
afterwards.
But
this
is
where
we're
going
so
this
Voth
is
in
the
general
area,
because
it's
for
all
of
things,
so
thank
you.
You
re
Thank,
You
Alyssa,
be
very
clear
here.
This
is
not
a
working
group
forming
bought.
A
This
is
a
hopefully
one-time
deal
where,
when
you
have
more
questions
and
ideas
afterwards,
you'll
talk
to
each
other.
We
have
a
mailing
list
which
is
at
the
bottom
of
this
slide,
and
but
there
is
no
intention
to
form
a
working
group.
We
are
discussing
two
documents
that
are
already
out
there,
so
there
will
be
more
discussion
of
them,
but
there's
no
idea
to
have
a
working
group
out
of
this.
So
why
we're
doing
this
is
that
we
want
to
have
many
people
have
said.
A
Oh
I've
heard
about
this
or
we're
using
github
a
little
bit
in
our
group
or
I
want
to
know
more,
and
things
like
that
and
sort
of
the
idea
is
to
is
to
socialize
it
I'm.
This
is
sort
of
the
old
school
kind
of
off
where
we're
actually
supposed
to
just
sort
of
say,
Oh,
your
internet,
I'm
interested
in
that.
So
here's
the
obligatory
humorous
slide
because
people
have
been
asking
me,
you
know
how
do
you
pronounce
that
all
of
those
are
valid
pronunciations
in
english
and
capitalization
counts?
A
Somebody
actually
asked
me
about
what
gift
up
is
so,
which
is
perfectly
reasonable.
Cuz
they
didn't
know.
What
get
was
someone
actually
earlier
asked
me
about.
Why
should
they
join
linkedin
and
it's
the
same
thing
capitalization
counts,
so
I
will
I
will
this
is
the
next?
Hopefully,
10
minutes
is
going
to
be
a
whole
bunch
of
slides
being
blown
at
you.
A
So
it's
an
incomplete
list
on
the
idea
here
is
not
for
you
to
write
down
all
the
notes
of
what
I'm
saying
but
to
when
you
see,
if
you're
interested
in
using
github
in
your
working
group-
and
you
see
a
working
group
that
either
you're
in
or
that
you
know
about
make
a
note
of
that
so
that
you
will
know
those
people
and
such
like
that.
All
of
this
is
also
being
discussed
on
the
mailing
list,
but
this
is
a
way
for
you
to
know
who's
doing
what
and
for
whom.
A
A
But
so
again,
just
look
at
these
are
the
highlights
and
I
will
zip
through,
because
really
what's
much
more
important
in
this
discussion
is
the
next
two
presentations
plus
the
discussion
at
the
end,
so
in
alphabetical
order,
Acme
uses
it
they,
oh
I'm,
sorry
so
one
of
here's
another
acronym
for
you,
folks,
it
I
for
I
meant
to
spell
it
out
earlier-
is
PRS
pull
requests
if
you're
not
familiar
with
github.
This
is
a
github
specific
feature.
A
Acne
uses
pull
requests
to
make
changes
even
within
the
document
authors
that
is,
they
use,
pull
requests.
The
document
authors
use
pull
requests
to
track
among
themselves
what
they
are
doing
and
why
they
try
to
track
all
the
issues
on
the
mailing
list
and
the
course
the
discussion
is
on
the
list.
I'm
anima
uses
it
for
some
things
and
it's
mostly
just
a
simple.
A
You
know
repository
depository
site
kind
of
thing,
geo,
Jason
part
of
the
reason
why
they
used
this
is
the
community
was
using
github
before
they
came
to
the
IETF,
which
is
a
good
reason
to
use
a
tool
if
you
already
know
how
to
use
a
power
tool.
That's
that's
a
good
reason
to
use
that
power
tool
and
not
to
go
back
to
hammers.
The
HR
pc
has
all
of
their
documents,
including
the
documents
like
for
meetings
and
such
on
github.
They
noted
here
that
the
repos
actually
owned
by
one
of
the
co-chairs.
A
This
is
a
funny
question
that
you
have
to
ask
is
when
you
create
a
github
repo
or
a
working
group
who
owns
it,
who
doesn't
own
it?
Who
gets
to
change
things
and
such
like
that,
so
they
noted
that
the
repos
owned
by
one
of
the
co-chairs-
and
they
also
notice,
noted
that
there's
no
single
place
where
issues
are
being
tracked,
that
of
course
sucks.
But
it's
also
common,
even
in
groups
that
don't
use
github,
HTTP
biss,
the
poster
child.
A
So
all
working
group
and
I
say
that
and
we
will
have
to
the
next.
Two
presentations
are
from
people
heavily
active
and
they
don't
agree
on
on
its
use
in
HTTP
pissed.
But
all
the
working
group
drafts
are
in
a
single
github
repo.
All
issues
are
tracked
their
on.
They
also
have
the
working
group
homepage
there.
So
when
you,
when
you
go
to
working
from
home,
page
you're,
actually
end
up
on
github,
you
can
tell
they
really
really
like
this.
A
The
materials
in
the
agenda
stuff
are
also
on
get
up,
so
they
pretty
much
are
using
this
as
the
home
place
for
everything
and
they
have
for
quite
a
while,
and
for
those
of
you
not
familiar
with
HTTP
bisque,
they
just
pushed
out
maybe
a
year
ago,
a
large
raft
of
documents
that
all
had
a
lot
of
interconnections
and
they
use
github
also
to
track
the
interconnections
so
there's
a
whole
bunch
of
IOT
groups
that
uses
use
github
for
their
documents
and
one
of
the
things
that's
common
here
with
them.
A
Is
that
because
a
lot
of
the
iot
groups
interact
with
groups
outside
the
IETF,
it
turns
out
that
having
all
of
their
stuff
or
having
a
lot
of
their
stuff
on
github
actually
makes
it
excessive
more
easily
accessible
to
people
who
are
outside
the
IETF.
Who
don't
want
to
be
on
our
mailing
lists
and
such
like
that,
and
so
the
open
connectivity
foundation.
Ocf
seemed
to
like
that.
So
that's
that's
a
thing
to
note
and
music
are
using
it
a
little
bit,
but
the
working
group
isn't
quick.
A
Everything
happens
on
github
because
quick
as
part
of
HTTP
biz,
nope
I,
didn't
say
that
I
didn't
say
that
oh
yeah
yeah,
yeah
so
yeah.
So
that
was
the
second
humor
slide,
but
and
a
few
things
that
aren't
on
github.
They
say
they
are
moving
to
github
so
again,
very,
very
active
use
for
quick
RTC
web.
They
said
yeah
most
the
docs
are
and
github
TLS
specifically
said
some,
but
not
all
the
documents
are
there
on
TLS
1.3,
something
near
and
dear
to
many
people's
hearts.
A
They
are
using
the
github
issue,
tracker
and
pull
requests
extensively,
meaning
that,
if
you
say
I
want
to
see
this
text,
they
really
want
to
see
that
as
a
pull
request
in
github
and
to
track
things
that
way
and
the
TLS
working
group
also
has
a
couple
of
other
drafts,
and
you
know
not
so
much
that
they're
using
github
on
that
trans
has
just
one
one
draft
on
it:
I
mean
humorously.
A
Here
they
actually
track
the
issues
with
track,
which
is
the
IETF
sponsored
tracking
that
only
a
small
number
of
working
groups
still
use
but
they're
using
github
for
the
document
itself.
So
that's
a
split
use.
Web
push,
sort
of
normal
some
of
the
drafts
are
in
issues
are
in
github
discussion
on
the
mailing
list,
okay,
so
that
was
it
for
the
roll
call
and
I
think
I
did
that
under
10
minutes.
A
So
again,
the
idea
there
is,
if
you
saw
a
working
group
you
are
interested
in
and
they
might
have
more
information
they
might
have
experienced,
go,
find
them
and
let's
move
forwards,
I'm
sorry,
oh
yeah,
there's
probably
other
like
I
said
at
the
beginning,
there
were
ones
who
just
didn't
you
know
say
anything
but
and
some
of
those
will
some
of
the
ones
who
didn't
say
anything
will
also
have
interesting
side
notes.
A
C
A
So
yeah,
so
that's
another
research
group
they're
using
so
let's
move
on
to
you
know
how
working
groups
are
allowed
to
use
third-party
services.
I
pulled
this
pretty
much
directly
out
of
the
abstract,
so
that
mark
could
take
is
time
to
get
up
to
the
mic,
and
now
I
will
switch
to
mark
slides.
Please.
D
Okay,
so
we've
been
using
github
in
HTTP
the
working
group
for
for
quite
some
time,
I
think
we
were
the
first
or
at
least
one
of
the
first
to
use
github
and
certainly
one
of
the
first
to
use
it
so
aggressively.
I
should
have
known
that
being
in
this
room,
it's
cold
and
people
want
you
close
to
the
mic.
D
We
have
people
come
up
regularly
and
say
well,
but
this
is
the
way
we've
done
it
before
and
are
you
sure
you
can
do
that
or
I
want
to
do
it
this
way,
and
that's
that's
a
very
reasonable
response
when
I
first
started
using
it
for
HTTP?
I
went
to
my
area
director
who
I
think
at
the
time,
was
mary
and
said:
is
it
okay?
If
we
do
this
and
he
thought
about
it,
we
talked
through
it
a
little
bit
and
he
said
yes
sure,
and
that
was
great.
D
So
I
had
a
little
bit
of
air
cover,
but
you
know
that
was
just
an
agreement
between
me
and
him
and
we
talked
to
the
working
group
about
it.
It
seems
to
me
that
it
would
be
nice
to
have
a
more
structured
approach
to
what
you
can
and
cannot
do
when
using
these
third-party
tools,
because
this
session
really
isn't
just
about
github
to
me.
Even
the
people
who
are
just
using
github
often
are
using
things
like
CI
systems
and
that's
another
third-party
tool.
D
Let's
go
to
the
next
line,
so
I
thinking,
you
know
what
one
thing
we
should
be
talking
about
in
all
of
this
is:
what
are
the
foundational
principles
that
we
think
about
when
we
use
a
third
party
tool
like
github
I,
use
tools
and
services
kind
of
interchangeably
here,
because
we
don't
really
have
a
terminology
for
this
yet,
and
so
you
know
that's
good
for
the
people
who
are
new
to
the
working
group
or
who
want
to
engage
casually
and
they're
used
to
engaging
in
other
mechanisms
in
the
ITF
in
that
they'll
have
more
assurance
that
this
working
group
is
operating
in
a
way
that
they
can
easily
understand
that
they're
using
tools
in
a
way
that
is,
you,
know,
equitable,
and
also
it's
good
for
the
working
group
who
wants
to
use
these
tools,
because
you
know
you
need
some
amount
of
air
cover.
D
You
need
some
sort
of
guidance
that
you're
doing
this
in
a
way,
that's
a
reasonable
for
the
IETF.
If
you
mess
this
up
it
is,
it
can
be
very
bad
if
we
use
a
tool
in
an
appropriate
way,
then
you
know
and
people
feel
that
their
disadvantage
of
the
process
that
can
break
down
the
entire
process
and
the
guarantees
we
have
being
in
the
standards
body
so
so
having
some
rigor
around
this
I
think
would
be
good
next
slide.
D
D
I
think
that
once
we
figure
out
what
they
are,
they're
relatively
long
lived
and
we
can
put
them
in
a
bcp
or
a
comparable
document
and
let
them
sit
there,
whereas
the
advice
about
using
github
in
particular
is
going
to
evolve
pretty
continuously
for
a
long
period
of
time,
and
it
may
be
that
an
RFC
is
the
best
up,
but
for
that
it
may
be
that
a
wiki
is
the
best
at,
but
for
that
we
can
talk
about
that
later.
So
next
slide
please.
D
These
are
the
ones
that
the
draft
talks
about
and
in
the
vest,
ITF
tradition.
I'm
not
going
to
regurgitate
the
draft
to
you.
If
you're
interested
in
this,
you
can
go
and
read
the
draft.
It's
not
very
long,
but
it's
just
a
list
of
high-level
principles
of
the
things
we
look
for
when
we
want
to
use
a
third-party
tool
to
make
sure
that
we're
using
an
appropriate
way-
and
that's
really
all
I
had
I-
can
talk
through
these
a
little
bit
of
folks
want.
But
that
was
the
proposal
that
I
made.
D
D
E
30
volts,
you
know,
one
of
the
things
is
that
what
what
how
do
you
define
working
group
use
is
something
you
know
if,
for
example,
like
you
know,
there-there's
for
the
DC
working
group,
we
do
use
github,
but
we
don't
really.
You
know,
use
it
in
a
broad
working
group
context.
We
use
it
more
for
the
two
co-chairs
to
sort
of
work
together
and
have
like
a
single
place
to
put
information
and
things
like
that.
E
You
know
and
we
have
used
it
for
like
a
few
documents
where
there
was
a
group
of
authors,
that
you
know
needed
stuff,
so
you
know,
and
we
didn't
really
think
about.
Oh,
this
is
going
to
be
a
big
issue
because
you
know
we
put.
These
are
just
tools
that
were
we're
using.
So
you
know,
how
do
you
define
a
working
groups,
use
versus
sort
of
this?
Not
private
use,
or
you
include
that
private
use
in
this
right.
D
I
kind
of
you
know
when
you
ask
that
two
things
come
to
mind.
One
is
that,
if
a
participant
you
know
would
reasonably
think
that
they
need
to
interact
with
that
tool
to
participate
in
the
working
group.
That's
using
that
tool
and
the
other
is,
if
you
form
a
hard
dependency
on
the
tool
where
you
know
you
have
significant
investment
in
that
tool
and
if
it
gets
taken
away
one
day,
then
you've
got
a
problem
as
a
working
group,
but
that
probably
means
you're
using
that
tool
to
because.
E
D
Can
you
just
give
a
brief
definition
of
what
you
mean
by
recoverability
I
mean
that
if,
for
example,
using
github,
if
they
were
to
plow
into
the
ground
tomorrow
and
lose
all
their
data
or
I
now
get
sued
in
submission
that
you're
working
groups
work
is
not
lost
right,
okay,
thanks
or
if
they
started
charging
40
million
dollars
per
user
or
something
you
know.
F
Kyle
rose
not
just
work,
but
history
right.
It's
not
just.
A
H
Creative
slides,
they're,
just
pictures,
so
part
of
the
point
of
this
draft
was
to
act
as
a
target,
so
hence
the
slide
so
mark
was
talking
about
the
larger
context.
We
talked
a
little
bit
about
other
tools,
but
obviously,
at
this
point,
the
primary
tool
that
we're
talking
about
is
get
up.
I
want
to
talk
about
the
specifics
in
a
little
more
detail
here
and
I'm,
not
actually
going
to
talk
about
the
drafter
a
little
while
because
I.
Think,
though,
Paul
did
a
great
job
of
the
introduction
here.
H
H
We
were
tracking
issues
there,
but
we
weren't
actually
doing
any
discussion,
but
it
meant
that
people
had
to
visit
get
home
to
get
the
state
of
the
working
group,
and
that
was
that
was
really
sort
of
the
first
time
that
we
did
that
and
as
an
editor
on
on
those
specs,
I
used
github
pretty
heavily
and
we
saw
a
lot
of
contributions
there.
That
was
successful.
So
I'm
a
bit
followed
and
when
we.
I
H
J
H
H
We
talk
a
lot
about
the
what
we
do
and
why
we
do
it,
but
the
how
is
is
kind
of
critical
and
move
I
think
we
have
some
reason:
we're
good
processes
for
deciding
what
work
that
we
do
when
forming
working
groups
and
how
we
select
chairs
and
editors
and
all
those
sorts
of
other
things.
That's
pretty
well
understood
now,
but
this
part,
the
next
part
and
I,
think
we
can.
H
We
can
talk
about
improving
the
process
overall
next,
so
the
underlying
principle
here
that
we're
working
on
is
we
that
I'm
looking
for
is
I
would
like
to
like
us
to
start
building
RFC's
the
way
we
build
software
and
thinking
about
it
in
some
of
the
same
terms,
not
not
necessarily
all
at
the
same
terms.
We
don't
necessarily
want
to
pick
up
all
of
the
baggage
that
we
had
there
but
start
to
think
about
it.
H
In
the
same
sort
of
terms,
so
next
and
I
think
that
the
target
that
we're
looking
for
here
as
an
organization
is,
we
want
high-quality,
open
source
software
I
mean
that
the
ioc's
that
we
develop
our
essentially
as
open
as
they
possibly
could
be,
and
we're
looking
to
meet
a
certain
bar
of
quality.
Next,
so
does
it
actually
mean
yeah
that
we
don't
necessarily
we're
not
we're
not
looking
for
ISO
9000
certification
here
or
anything
like
that?
H
We
also
don't
build
software
that
meets
it.
So
that's,
okay,
right!
My
trainees
got
a
date
on
that,
but
really
not,
and
but
some
of
the
principles
they're
actually
do
apply
in
terms
of
do
you
have
a
reproducible
process?
H
Do
you
actually
understand
what
process
you
use
to
produce
the
output
that
you
have
all
those
sorts
of
questions
come
in
next,
so
to
some
extent,
a
lot
of
this
relies
on
the
degree
of
quality
assurance
that
we
have,
and
we
have
a
bunch
of
processes
in
in
place
that
that
allow
us
to
control
the
quality
of
the
output
that
we
have
and
we
have
cross
area
review
teams,
directorates
and
and
the
likes.
We
use
a
tenets
to
sort
of
do
this
at
low
level.
H
Basic
checking,
Shepherd's
automation,
but
we
actually
see
some
working
groups-
are
taking
this
a
little
further
than
this
and
I
think
that
the
the
working
groups
that
are
producing
yang
models
are
actually
pretty
far.
I
had
a
lot
on
this.
They
actually
have
tools
that
take
the
the
schema
documents
they
have
and
turn
them
into
the
textures
in
the
documents
they
have
automated
validation
for
those
things
and
pretty
good
tool
chain
around
those
sorts
of
things
and
I
sort
of
previous
hackathons
and
some
pretty
impressive
work
in
that
area.
H
So
listen,
there's
some
interesting
things
that
we
could
potentially
be
doing
in
that
service
packs.
Next,
so
one
of
the
principles
that
I'm
particularly
fond
of
is
this
is
the
this
notion
that
you
continuously
about
validate
what
it
is
that
you've
produced
and-
and
this
is
something
that
I'd
like
to
to
get
in
the
process.
H
Some
of
those
people
who
are
using
some
of
the
tools
that
are
available
for
github
are
actually
now
taking
advantage
of
the
fact
that
the
document
produces
valid
text
every
commit,
that's
something
that
I've
worked
on.
We
can
enable
that
if
people
are
generating
pull
requests
against
the
quick
spec,
you
will
actually
see
a
little
red
mark
down
the
bottom
if
you've
done
something
wrong
and
it's
not
able
to
produce
a
valid
document
out
of
the
the
changes
that
you've
made,
and
so
that's
that's
valuable
that
keeps
the
process.
H
Nice
and
smooth
is
essentially
grease
on
the
wheel,
but
it's
a
pretty
low
bar
to
me.
There
are
specifications
in
this
organization
that
actually
include
code
not
a
great
deal,
but
some
of
them
a
lot.
It
would
be
nice
if
that
code
actually
compiled
when
we
ship
it
and
ensuring
that
that
is
continues
to
remain
true
is
something
that
would
be
interesting
as
well.
H
For
instance,
it's
really
nice
if
the
ex
the
examples
in
those
documents
are
actually
correct,
based
on
the
definitions
in
the
documents
and
those
people
who
are
using
schema
language
languages
to
express
what
it
is
that
they're
doing
can
take
advantage
of
automatic
validation,
and
the
underlying
principle
here
is
keep.
It
short.
Make
sure
that
you
learn
about
this
thing
quickly
next,
so
this
is
my
very
crude
diagram
showing
how
it
is
that
we
produce
a
document
at
the
moment.
H
Our
major
forms
of
feedback
into
this
process
are
the
two
big
orange
lines
those
happen
after
we
publish
revisions
to
drafts
and
they
happen
at
meetings,
and
it
tends
to
happen
that
next
slide
that
the
feedback
cycle
is
about
this
long,
and
you
are
here
now
right-
welcome.
Thank
you
for
participating.
H
We
thank
you
for
joining
us
once
every
four
months.
For
this.
Oh,
that's
kind
of
bad.
Our
next
slide,
the
real
validation
we
get
for.
These
things
is
when
people
actually
implement
and
deploy
them
turns
out.
That
doesn't
happen
anywhere
near
often
enough.
One
of
the
reasons
I
think
that
the
HTTP
to
work
was
successful
was
two
things.
One
is
that
we
reduced
the
four-month
loop
to
effectively
a
two-month
loop,
and
the
other
was
that
we
did
this
implement
and
deploy
thing.
H
Yeah
so
so
I'll
repeat
what
Mark
said:
we
were
childhood
at
the
beginning
of
the
year
the
implementation
draft
went
out
in
June
and
it
was
deployed
in
august
10
implementations
at
that
time,
not
ten
deployments
but
yeah
and
we're
sitting
in
it.
At
an
interim
discussing
some
changes-
and
someone
said
oh
yeah
I'll
have
that
on
twitter
com
tomorrow.
H
Next
line,
so
part
of
the
problem
here
is
that
we
have
humans
in
a
loop
in
order
to
turn
a
specification
into
code.
You
need
someone
to
actually
write
the
code
and
it's
not
usually
a
trivial
task.
The
hackathon
is
a
huge
improvement
in
this
regard.
We're
actually
getting
some
really
good
feedback
on
this
on
processes
and
development.
Net
VC
neatly
avoid
this
problem.
H
H
Also
so
you're
concerned
about
ownership
yeah,
so
we
now
know
well,
actually
we.
H
H
H
They
ask
questions
and
they
say.
Why
is
it
like
this
and
we
can?
We
now
have
the
tools
available
to
us
to
go
back,
find
the
issues
that
we
were
using
identify
the
discussion
that
was
happening.
It's
a
lot
easier
to
do
that
with
with
an
issue
tracker
rather
than
trying
to
search
through
mail
archives,
and
you
can
actually
see
why
you
made
that
particular
change
and
who
made
that
change.
H
And
that's
that's
a
pretty
powerful
thing,
as
I
said,
threading
in
context
is
kind
of
important
and
I
find
that
having
a
discussion
in
context
has
been
quite
useful
and
quick.
So
we
decided
at
some
point
to
move
from
the
model
where
the
issues
were
merely
being
tracked
in
github
to
actually
allowing
substantive
discussion
on
github
and
that's
been
pretty
pretty
valuable
too
and,
as
I
said,
minor
changes
are
much
easier
to
handle.
H
Fixing
grammar
realigning
the
the
stupid
ascii
art
that
we've
been
forced
to
draw
those
sorts
of
things,
and
so
it's
not
the
problem
that
Paul
was
concerned
about
that's
not
being
an
issue
thus
far,
but
it's
certainly
one
worth
discussing
I.
Think
that's
all
I
have
oh
yeah
I'm
supposed
to
remind
people
of
what's
actually
in
the
draft
next.
Is
it
basically
says
well
what
it
is,
how
to
decide
to
use
it?
H
What
to
use
it,
for
it
says
some
of
the
same
things
that
mark
strife
does,
although
I
think
marks
draft
sort
of
covers
it
more
cleanly,
particularly
with
the
principles
that
is
outlined.
It
does
have
some
more
specific
advice
on
how
to
how
to
manage
things
and
also
some
general
blathering
about
very
thinks.
It
was
never
intended
to
be
published
as
the
the
stocks
at
the
front
indicated,
it
was
meant
as
a
target
where
we
were
someone
was
threatening
to
have
a
working
Boff
and
feel.
H
Was
a
threat
of
having
a
buff
with
with
no
documents,
oil,
no
substantial
targets
for
discussion
and
I
thought
that
that
was
just
not
on
so
I
put
this
together
thanks
to
a
layer
for
actually
like
fixing
it
because
it
was
a
dire
state
before
she
fixed
most
of
that.
So
it
was
pretty
bad.
Let's
be
frank,
so
that's
all
I'll
blathering
in
there,
and
it
also
has
one
other
thing:
github
is
not
available
over
ipv6,
so
the
community
can
shed
it
here.
A
M
A
This
is
only
resident
and
by
the
way,
just
just
as
a
point
we
have
about
15
or
20
minutes
just
and
I
assume
we're
going
to
fill
it
with
the
bike
line.
Do
pay
attention
to.
We
do
have
a
mailing
list,
I'm
sure
this
is
going
to
generate
stuff
for
the
mailing
list,
but
feel
free
to
Mike
line
for
about
15
or
20
minutes.
Mark
thanks.
So.
L
Is
let's
not
go
through
this
process
again,
where
we
get
stuck
on
a
tool,
because
all
of
us
in
this
community
love
that
tool
and
then,
when
new
people
start
coming
to
the
community
look
at
us
ago,
using
that
stupid
tool,
some
sort
of
agility
with
our
about
you
know
our
use
of
different
tools,
different
ways
of
working
together
so
but
that
continued
to
plug
into.
At
the
end
of
the
day,
we
have
something
stable
that
we
can
point
to
and
say
that's
what
we
mean
for
now.
As
the
standard
and
by.
A
N
N
Micah,
bishop,
so
I
will
say
the
HGP
working
group
being
my
first
working
group
coming
into
I
kind
of
saw
this
from
the
beginning
and
I
didn't
know
the
old
process,
but
I
wasn't
familiar
with
github
either.
So
it
has
been
surprisingly
good
to
collaborate
there,
although
I
had
to
learn
get
in
the
process.
N
The
thing
that
has
been
most
frustrating
to
me,
particularly
now
that
I'm
a
doc
headed
or
in
quick,
is
we
don't
really
have
an
agreed
way
to
reach
consensus,
and
so
we-
and
we
continue
to
have
this
I
ATF
process.
That
consensus
is
on
the
mailing
list.
Consensus
is
not
in
meetings.
Consensus
is
not
on
github,
and
so
we
have
something
like
a
hundred
ish
resolved
issues
and
quick,
and
we
have
formal
consensus
on
one.
D
So
with
my
quick
working
group,
chair
hat
on
co-chair
Lars
is
out
to
see
about
to
say
we
don't
even
have
it
on
that
one.
We
we
just
we
just
started,
as
you
know,
I
put
out
a
call
for
consensus
about
a
week
ago
on
how
many
were
there
to
me
way
too
many
issues.
So
we
have
been
feeling
our
way
through
this
process
and
I
put
a
link
on
to
the
jabber,
which
is
another
way
that
we
communicate
here
at
the
IDF.
D
Business
to
our
contributing
document,
which
is
a
we,
we
started
this
in
HTTP
working
group
where
github
allows
you
to
have
a
file
on
the
rep,
oh,
that
is
automatically
shown
to
people
or
linked
to
people
when
they
create
an
issue
or
do
certain
things
on
the
repo,
and
this
is
the
terms
of
contribution
and
you
kind
of
evolved
that
over
time
to
be.
You
know
this
is
how
you
participate
in
this
working
group.
D
This
is
how
we
get
to
consensus
in
this
working
group
and,
if
folks
are
on
the
jabber
channel,
I'd
I'd
encourage
you
to
read
that,
because
that
reflects
how
we're
working
right
now
in
terms
of
getting
to
that,
but
I,
think
your
your
feedback
there
is
is
good.
That
makes
me
more
concerned
about
the
state
we
charted
quick
in
than
anything
else.
D
N
N
D
J
Ted
Hardy
I,
chair
rgc,
web
and
acne,
both
of
which
use
github
in
very
different
ways,
and
one
of
the
things
I'd
like
to
point
out
is
that
I
think
its
point
about
don't
get
caught
in
a
tool
for
all
time
needs
to
be
extended
slightly
to
understand
that
you
may
use
different
tools,
not
just
for
different
working
groups
but
for
different
life
cycle
points
in
a
working
group
and
I'll
point
out
that
an
HTTP
nobody
suggested
going
to
github
while
we
were
still
in
the
here.
Are
these
three
candidate
drafts
stage
right
the
leader?
J
You
are
in
the
process,
the
more
appropriate
the
github
style
of
we
already
have
the
structure
and
we're
making
contributions
to
it,
etc.
The
more
natural
that
feels
at
least
to
me
and
if
you're,
really
still
at
the
stage
where
somebody
may
need
to
say
nope.
This
whole
approach
is
wrong:
they're
not
going
to
do
that
as
a
as
a
giant,
PR
emptying
and
replacing
a
document,
they
have
to
do
it
as
a
new
document,
and
so
there's
a
yeah.
It's
been
done,
Richard
points
out
to
me.
J
J
My
chicken
draft
and
on
yes
I
was
it
was
excellent.
But
the
point
is:
let's
not
either
get
stuck
on
using
this
particular
tool
or
assume.
We
have
to
use
the
same
tool
through
the
life
cycle
of
a
working
group,
but,
as
it
may
very
well
be
that
this
is
a
very
useful
tool
for
authors
in
the
early
stage
and
then
becomes
a
working
group,
a
tool
as
the
after
adoption
when
things
get
get
later
along
and
that
sort
of
evolution
should
be
part
of
how
we
think
about
it
as
well.
O
Hello,
I'm
binoculars
so
I
like
what
you
what
you
wrote
right,
having
RFC
producing
RFC
the
same
way
with
your
software,
so
you
mentioned
the
yang
tools
and
explain
what
I'm
doing
there
and
what
my
main
pain
point
is.
So
what
I'm
doing
is
that
every
day,
I'm
looking
at
all
the
drafts,
the
new
ones
I
run
a
tool
to
extract
a
young
module.
Then
I
validate
this
then
I
report.
O
It
then
I
report
errors
on
the
lines
and
then
the
lines
under
the
same
one
that
the
original
one,
because
you
know
extra
lines
whatever,
because
the
footer
my
biggest
issue
here
is
that
we
should
distinguish
the
draft
from
something
which
is
in
there,
like
a
module,
emit
some
code
this
one
if
it
would
be
in
github.
That
would
help
me
a
lot
I
happen.
H
O
N
Hi
Dave
Crocker,
so
I
I
get
the
degree
of
adoption
that
has
already
happened,
and
that
makes
moot
any
concerns,
one
my
Gray's
about
whether
it
should
be
adopted.
So
any
comments
I'm
going
to
make
aren't
raising
that
question,
even
if
they
might
sound
like
they
are.
N
We
stuck
with
text
only
for
rfcs
for
dramatically
longer
than
anybody
would
have
thought
was
a
good
idea
and
we
didn't
just
do
it
because
we
were
encrusted
in
it.
There
was
a
facility
with
it
and
an
ease
of
access,
an
accessibility
that
was
profound
and
Liz
and
in
spite
of
the
fact
that
we're
now
using
XML
as
a
base,
we're
actually
producing
text
documents
and
and
I'm
amused
by
the
fact
that
the
HTML
version
that
we
produce
is
only
a
slight
variation
of
the
ASCII
version.
N
We
don't
even
use
pretty
HTML
to
the
extent
we
could.
This
conservativeness
in
transitioning
over
to
more
powerful
and
more
complex
tools
is
something
that
we
can
forget
the
benefit
of
the
barrier
to
entry
with
github
compared
to
the
barrier
to
entry
of
generating.
Forgive
me
a
text
document
is
huge,
so
the
benefits
are
significant,
but
we
can
get
lost
in
in
the
the
enthusiasm
of
that,
forgetting
that
we've
just
raised
the
bar
for
entry.
N
I,
don't
know
where
to
go
with
that
concern
other
than
up
here,
raising
the
flag
about
it,
and
some
of
the
comments
being
made
I
think
reduced
to.
We
need
to
figure
out
more
careful
discipline
for
using
this.
That,
doesn't
I
say,
more
careful.
I
don't
mean
that
people
are
doing
anything
wrong.
I
think
that
we're
not
necessarily
thinking
carefully
enough
about
the
selectivity
that
we
might
want
to
have
and
there's
any
number
of
comments
that
I
think
fit
into
that
view.
N
D
Very
much
like
we've
put
a
fair
amount
of
thought
into
that.
So
I'd
encourage
you
to
look
at
the
link
that
I
gave
that
on
jabber.
We've
been
very
conscious
to
make
sure
that
someone
who
does
not
want
to
use
one
of
these
tools
has
legitimate
ways
that
they
can
participate
in
the
activity
and
I'd
actually
push
back
on
your
characterization
that
we're
raising
the
bar
for
many
many
people.
H
And
and
to
add
to
that,
the
the
process
by
which
you
you
produce
a
text
document
that
the
submission
tool
will
accept
is
torturous
if
you
don't
have
access
to
tools
that
help
you
in
that
process,
and
we
do
have
some
pretty
good
tools
now
that
allow
you
to
do
something
as
simple
as
rights
and
mark
down
and
throw
it
at
the
wall,
and
it
tends
to
stick
at
that
point
as
opposed
as
opposed
to
bounce
off
and
hit
you
in
the
face.
Okay,.
G
Thank
Joe,
Hildebrand
I
just
wanted
to
point
out
one
more
thing
about
the
contributing
document
that
you've
got.
It
does,
I
think,
have
a
link
to
the
know
well
in
it,
and
I
just
wanted
to
point
out
that
there's
really
no
way
to
either
send
a
PR
or
file
an
issue
without
having
seen
them
the
the
note.
Well,
so
that's
for
the
people
who
are
concerned
about
you
know
blue
sheet
style
issues,
that's
at
least
one
of
the
mitigations
for
that,
and
we
can
track
you
back
to
to
your
account
on
github.
A
Michael
before
you
start
a
you
said,
blue
sheet
show
who
has
not
signed
the
blue
sheet:
okay,
witness
ms
room
so-,
michael
richardson.
Can
you
go
back
to
the
diagram
with
the
circle?
The
last
the
last
iteration
circle,
with
a
really
tight
loop,
you're
asking
me
to
do
significant
things
here?
Okay,
I
think.
P
A
A
You
so
so
something
that
that
I
think
that
is
a
big
deal
is
that,
despite
the
lovely
Miss
of
the
green
loop
on
the
loop
through
the
meeting
still
exists
and
it's
a
I
think
I
think
it
can
be
a
little
bit
jarring
to
a
design
team
that
has
been
iterating
quite
quickly.
For
instance,
the
inanimate
strap
design
team.
A
Think
that's
is
that
this
is
the
part
of
the
problem
that
we
have
between
say,
for
instance,
where
day
Crocker
is,
and
this
is
that
we're
iterating
an
awfully
fat
awfully
fast
there
and
that's
good,
but
that
we
have
an
impedance
mismatch
with
a
larger
group
and
this
kind
of
thing.
So
one
of
the
things
that
I
did
is,
I
would
actually
publish
an
awfully
long
email.
A
You
know
500
lines
or
something
long,
which
was
our
notes
of
our
thing,
and
I
would
try
to
condense
our
diffs
and
awe
and
things
that
we
did
back
to
the
mailing
list
and
now
and
then
there's
someone
pull
something
out
of
of
it
right
in
the
middle
and
there's
a
big
rat
hole
there.
That
they're
want
to
talk
about
and
that's
good
because
they
paid
attention
to
read
that
far
and
I.
A
H
A
Let's
get
the
thing
out
so
that
the
diff
tool
can
really
clearly
say
to
people,
and
here
was
the
controversial
change
between
version
4
and
version
5,
and
there
are
other
stuff
between
version
3
in
version
four
was
editorial
nitpicky
blah
blah
blah.
We
reformatted
this.
We
moved
some
text
here.
We
did
that
and
just
do
that
and
not
wait
till
the
Monday
or
two
weeks
ago
to
do
it
or
when
week
ago
and
I.
That's.
Why
that's?
A
R
R
Switching
switching
points
is
there
such
a
short
line
behind
me
and
consensus
on
issues
has
very
frequently
in
our
contexts
been.
The
mailing
list
knows
that
the
issue
has
been
raised.
The
mailing
list
knows
that
there
has
been
a
resolution
and
the
two
people
who
really
care.
I
agree
with
a
solution.
R
R
This
doesn't
fit
the
description
that
this
and
the
RFC
is
that
the
IDF
lives
and
dies
by
that
I
think
it's
in
practice
quite
useful.
What
we
should
be
sure
of
is
that
anyone
who
follows
the
work
cannot
claim
to
have
been
surprised
if
he
has
fun.
He
has
read:
read
the
standard
means
of
communication
as
long
as
he
cannot
claim
to
be
surprised.
A
K
Keith
moore
I'll
try
to
be
brief.
I
do
have
two
points
in
no
particular
word
when
the
slide
was
up
there.
That
says
we
want
to
develop
documents
like
we
do
open
source
software.
My
first
thought
was
but
good
open
source
software
and
a
good
standards
document
really
have
very
different
characteristics
and
the
tools
that
you
use
to
collaborate
affect
the
product
in
in
both
good
and
bad
ways.
I
actually
think
this
is
a
great
idea.
H
To
creeping
fig
tourism
and
standards,
yeah,
just
just
to
respond
to
that,
Keith
I've
worked
in
a
number
of
different
standard
or
standards
organizations,
and
this
is
probably
the
one
place
that
I've
been
that
doesn't
suffer
from
that.
All
of
the
other
standards
bodies
that
I've
participated
in
have
massive
problems
with
feature
creep
and
I
think
this
is
just
a
sim
product
of
the
maturity
of
the
people
involved
and
and
the
the
culture
and
the
discipline
that's
applied
to
the
development
of
the
standard.
H
S
S
K
H
And
that's
actually
something
that
my
document
talks
about
a
little
bit.
I
didn't
mention
it
here,
but
I
should
have,
which
is
that
one
of
the
properties
that
were
actually
getting
is
that
the
editors
become
custodians
of
the
document,
rather
than
actually
being
responsible
for
writing
all
of
the
text.
And
that
is
a
huge
advantage
for
editors,
particularly
being
an
editor
on
a
number
of
those
documents.
But
you
still
have
that
that
level
of
editorial
review
nothing.
K
Is
quite
second
point:
is
that
any
time
I've
ever
had
to
try
to
like
assess
this
sort
of
mental
state,
all
the
ideas
and
the
decisions
taken
in
this
kind
of
thing
and
there's
been
multiple
sources
of
this
information
that
were
in
disparate
places.
It
becomes
a
problem,
so
I
think
doing
it.
When
everything
was
done
on
the
mailing
list.
You
knew
where
to
find
all
this
stuff.
It
was
all
on
the
mailing
list.
C
As
the
one
I
want
to
echo
back
the
contribution
or
like
a
blue
sheet,
one
so
I
think
you
already
mentioned
that
the
github
is
has
a
facility
to
specify
contribution
guide
which
you
have
to
look
except
in
which
is
standard
for
all
of
the
this
open-source
software.
You
have
to
accept
some
contribution
guide
in
order
to
contribute,
and
the
second
one
I
like
github
get
up
is
a
great
tool,
but
I'm
not
sure
that
the
recoverability
for
issues
and
pull
request
is
either
possible
or
available.
At
this
moment,
it.
A
F
Cohen-Chang,
a
fan
of
all
this
and
think
you
can
solve
these
problems
easily.
I
think
that
you
need
to
take
the
IPR
problems
very
serious
and
that
many
of
us
are
being
sued
right
now
over
a
lawsuit
that
were
largely
turn
on
whether
somebody
was
in
violation
in
bc,
78
or
not,
and
it's
a
lot
of
money
and
it's
going
to
be
traced
back
to
actual
people
and
wednes
blue
sheets.
It's
easy
to
do
in
this
year.
You
dear
there's
a
community.
You
know
that.
F
But
when
it's
you
know
XX
27
on
github,
it's
really
hard
to
correlate
that
with
a
real
persons
name.
So
I
I
want
us
to
move
to
those
types
of
tools
and
take
things
from
people
that
maybe
we
never
meet
in
person.
But
I
think
that
we
have
to
be
able
to
actually
address
the
the
legal
issues
that
come
out
of
that
as
well
yeah.
So.
D
F
All
I'm
saying
is
I
think
we
have
to
get
very
seriously
looking
at
this
experience
of
a
fort
of
educating
our
editors
on.
What's
major
and
what's
not
magic,
major
okay,
at
which
I
suspect
that
from
Martins
look
he
doesn't
know,
and
then
the
other
thing
is
is
looking
at
the
the
what
for
the
ones
that
are
major.
What
what
is
our
bar?
So
w3c
has
a
very
clear
one
right
and
they
understand
it.
They
have
tools
that
enforce
it.
We
can
have
all
those
things,
I'm
nots
just
so
we
need
that.
I'm
not!
H
F
Even
with
the
email,
just
I,
don't
think
it's
the
email
address
that
was
necessarily
important
in
here.
I
mean
I'd,
like
I,
mean
I
use
fluffy
that
I
I
I've
her,
but
even
though
often
mind
yet
San
Francisco
I
think
that
often
we
do
through
the
community
process
of
participating
in
meetings,
know
who
the
people
are
and
no
and
makes
somewhat
different
and
that
we're
trying
to
make
that
more
remote
and
accessible
to
more
people.
It's
a
good
thing,
but
we
need
to
trust
that
right
and.
Q
Yeah
hi
Alyssa
Cooper,
so
I
thought
this
is
a
really
fantastic
discussion.
Thank
you
all
for
initiating
it
and
all
of
you
for
contributing
I'm
trimming
on
the
list.
I
think
you
are
now
we're
just
sort
of
chatting
about
what
are
the
takeaways
in
the
next
steps,
and
it
sounds
like
there's
really
a
few
different
categories
of
potential
future
work
here
or
future
areas
of
exploration.
So
there's
this
at
the
level
of
the
principles
which
is
kind
of
encompassed
by
marks
document.
Q
I
think
that's
that's
one
thing
there's
I
think
questions
around
four
working
groups
that
are
looking
to
upgrade
their
tooling
or
start
using
github
more,
but
aren't
really
using
it
right
now,
there's
obviously
a
lot
of
experience
now
in
the
IETF
and
I
think
there's
questions
to
explore
about
how
do
we
make
it
easier
for
new
people,
different
people
who
want
to
adopt-
or
you
know,
learn
from
what
what
we've
already
learned?
How
do
we
make
that
easier?
Q
So
there's
part
of
that
which
is
about
best
practices
and
part
of
it,
which
might
be
about
some
tooling
that
we
could
provide
as
the
ITF.
So
that's
another.
The
third
one
gets
to
Martin's,
going
to
think
about
the
sort
of
philosophy
of
how
we
develop
documents
and
four
groups
that
really
want
to
be
more
on
the
cutting
edge
or
experimenting
with
that
sort
of
thing
again.
Are
there
things
that
we
could
do
help
or
make
that
easier
or
make
it
more
acceptable
in
the
community
or
in
the
groups?
Q
That's
that's
another
one
and
then
lastly,
I
do
think
there
was
this
question
raised
both
bye,
bye,
Mike,
bishop
and
by
Harold.
That
is
a
little
bit
thorny
or
about
you
know,
does
the
does
you
know?
Potential
adoption
of
a
new
tool
by
by
some
parts
of
the
community
imply
anything
about
how
we
should
think
about
how
we
gather
consensus
and
how
we
make
decisions,
and
should
the
mailing
list
still
rule
the
day.
That's
obviously
a
question
that
needs
a
lot
more
further
deeper
thought.
Q
I
tend
to
think
that,
even
if
we,
you
know,
go
down
the
path
and
have
a
good
discussion
about
that
from
the
tooling
perspective,
we
always
want
to
make
it
such
that
people
are
able
to
use
the
tools
that
are
comfortable
for
them.
I,
don't
think
I
don't
hear
anybody
arguing
for
let's
get
rid
of,
or
you
know,
prohibit
that
any
tools
that
we
already
use-
which
I
think
is
good,
but
we're
mostly
talking
about
adding
and
you
know,
adopting
different
models
for
different
crowds.
But
I
do
think.
Q
That
is
like
a
process
point
that
if
people
want
to
debate
that,
then
I
encourage
you
to
take
that
to
the
to
the
mailing
list.
We're
going
to
keep
the
mailing
list
open
and
I.
Think
for
all
of
those
areas
that
I
just
listed
probably
further
debate
and
discussion
on
the
mailing
list
is,
is
the
right
next
step?
If
people
think
there's
other
things,
we
should
use.