►
Description
A
Okay,
so
welcome
to
the
no
GS
technical
steering
committee
meeting
for
February
19
2020
will
follow
our
standard
agenda,
as
was
outlined
in
issue
820
in
the
TSE
repo.
We
have
a
fairly
light
agenda,
but
James
has
an
update
on
quick
and
we
can
also
go
through
an
update
on
the
other
strategic
initiatives
as
well.
So,
first
of
all,
does
anybody
have
any
announcements
or
things
that
they'd
like
to
share
before
we
get
started?
I.
A
A
Other
than
that,
let's
move
on
to
the
issues
which
are
tagged
for
the
agenda.
The
first
one
is
no
J's
future
directions.
Any
interest
in
online
or
personal
summit
issue,
797
I'd
open.
That
I
was
just
thinking
that,
given
that
you
know
we've
we've
finished
our
first
successful
ten
years
of
no
GS
would
be
a
good
time
actually
to
get
together
reflect
about
what
we
think
will
make
no
GS
successful
for
the
next
ten
years.
There
seemed
to
be
some
issue
interest
in
the
issue.
A
You
know
and
there's
some
discussion
there
around,
aligning
it
with
one
of
the
collaborator
summits,
although
I
I
find
those
personally
are
already
pretty
busy,
and
also
the
idea
of
potentially
doing
it
online
as
opposed
to
in
person,
so
I
thought
it'd
be
good
to
spend
a
little
bit
time.
You
know
getting
some
additional
input
from
the
people
are
here
and
figuring
out.
You
know
if
it's
something
we
think
we
should
do
how
much
interest
there
is
and
sort
of
the
format
that
would
make
sense.
B
A
A
A
A
A
A
B
A
A
E
A
A
A
C
G
A
G
So,
at
least
for
myself
one
thing
that
may
be
helpful
before
we
make
any
strong
decisions
about
whether
or
not
it
should
be
remote
or
in-person
or
what
it
would
even
look
like.
It
may
make
sense
to
start
kind
of
drumming
up
what
the
agenda
might
look
like
and
what
kind
of
content
there
would
be
for
the
modules
team.
For
example,
we
had
an
online
summit
where
we
all
gave
talks
about
like
subsystems
that
we
were
working
on
on
our
vision
of
it,
and
that
was
extremely
helpful.
G
We
recorded
it
and
glued
online
so
something
like
that.
Maybe
super
productive
and
able
to
work
remotely,
whereas
if
we
want
to
do
something,
that's
closer
to
like
a
large
collaborative
call,
that
may
be
harder,
but
I
kind
of
feel
like
having
an
idea
of
the
shape
of
the
agenda
and
what
we
would
focus
on.
G
More
specifically
would
help
us
figure
out
if
a
remote
makes
sense
and
B
that
it
does
make
sense
to
be
a
separate
thing
from
our
existing
collaborate
or
somebody
not
to
call
him
to
question
the
fact
that
we've
said
that,
but
just
like
I
think
iterating
on
the
agenda
would
make
it
clearer
that
they
are
in
fact
two
separate
events.
Yeah.
G
A
G
This
could
also
in
theory
and
I'm,
just
thinking
aloud
be
some
sort
of
regularly
occurring
slightly
longer
call,
rather
than
one
very
long
day,
so
something
that's
like
an
hour
every
quarter,
or
something
like
that.
So
we
continue
to
iterate
on
that
vision
rather
than
a
FEMA,
one-off,
but
I.
Think
there's
like
a
couple
different
forms
that
this
could
take,
depending
on
the
explicit
content
that
we
want
to
do.
A
Yeah,
that's
true,
I
think
certainly
you're
right,
like
going
forward
the
like
doing
it
more
regularly
shorter
could
make
sense
as
well.
I
I
was
just
the
is.
My
starting
point
was
our
existing
ones
where
we
gotten
together,
and
it
was
pretty
productive
to
have
people
for
a
longer
period
of
time.
But
you
know,
depending
on,
like
you
said,
depending
on
the
agenda,
we
can
come
up
with.
Something
else
might
make
sense.
A
G
And
there's
also
the
possibility
I'm
just
separately
from
this,
that
for
the
collaborator
summit,
especially
if
multiple
projects
are
interested
in
having
their
own
project
focused
stuff,
that
we
could
possibly
even
earmark
half
a
day
at
the
collaborator
summit
for
this.
But
that
doesn't
preclude
us
doing
it
at
other
times
or
other
ways.
A
A
So
yeah
so
yeah
if
we
made,
if
we
basically
made
the
decision
that
hey
this
is
the
prior.
This
is
the
priority
and
we're
gonna
like
this.
The
challenge
I
always
find
just
like
people
want
to
be
at
everything
right,
so
we
want
to
not
force
you
to
to
miss
out
on
something
like
this,
because
there's
something
else
you
want
to
go
see
as
well.
Yeah.
G
A
A
B
A
B
A
B
It
should
be
quick,
so
many
puns,
you
may
get
mad
I'd
say
late.
Last
week,
I
updated
the
pull
request.
The
draft
pulled
forth,
the
very
sequence
update
from
Ferguson,
it's
still
massive
four
clusters
and
in
part
because
the
openness
of
self
configuration
had
to
be
regenerated,
so
there's
at
least
one
commit
in
there.
B
The
most
significant
issue
around
click
right
now
is
going
to
be
the
timing
of
OpenSSL
support
as
a
reminder.
What
I
would
what
we
had
to
do
to
get
quick
working
and
the
first
place
was
basically
back
port,
boring
SSL
introduced
some
quick,
specific
api's
have
been
back
ported
to
open
SSL
3,
there's
an
open
PR
for
that
I
I
had
to
further
back
port
those
to
the
version
of
one-one-one
that
we're
using
and
I
have
to
maintain
that
back
port.
B
B
They
they
put
out
a
blog
post
a
few
days
ago
at
the
basically
said.
If
they
choose
to
do
anything
on
this,
though
you
know
they
may
do
their
own.
Complete,
quick
implementation
is
kind
of
kind
of
makes.
My
brain
hurt
a
little
bit
there.
This
not
committing
whatsoever
to
to
what
they
want
to
do
here,
and
it's
not
clear
even
if
they
completely
understand
what
what
the
needs
are
here
open,
SSL,
3
old.
The
beta
is
currently
scheduled
for
June
of
this
year.
B
The
quick
drafts
will
not
go
to
the
iesg,
which
is
the
the
body
that
actually
finalizes
the
RFC
that
I
did
until
July.
So
just
if
we're
looking
at
just
timing
alone-
and
it
makes
sense
for
open
for
quick
not
to
go
into
open
SSL
3,
oh
so
that
what
that's
going
to
mean
is
we
have
to
float
these
patches
for
longer
and
they
will
not
be
officially
supported,
open
us
up
functionality,
which
means
we
have
to
keep
it
experimental
in
node
for
longer.
B
So,
that's
you
know
it's
a
wrinkle
the
patches
work
when
you're,
not
using
quick.
They
have
no
functional
changes
whatsoever
to
OpenSSL
as
it
you
know,
as
it
is
now
so
there's
not
a
risk
breaking
anything
else
in
OpenSSL
we're
not
exposing
any
like
security
vulnerabilities
when
quickest
not
being
used
right,
I,
don't
think,
there's
a
risk,
but
it
does
mean
things
like
if
you're,
using
the
shared,
open,
SSL
library
and
quick,
won't
work,
you'll
have
to
use
the
version
that
statically
linked.
A
B
B
E
G
B
B
B
B
There,
the
other
possible
thing
that
we
could
do
here.
It
also
pushes
out
timeline
and
something
I
think
we
should
explore
anyway
is:
can
we
possibly
reopen
the
question
of
that
possibility
of
using
boring
SSL
as
an
alternative
to
open,
SSL
and
I
know
that
has
its
own
challenges?
The
fact
that
there's
no
TLS
or
not
not
to
us,
know
long
term
support
for
boring
as
a
zone.
F
B
F
Been
working
with
Shelley
a
bit
on
adding
support
for
bonuses,
all
that
you're
at
least
able
to
bid
note,
but
as
I
said,
it
means
you
lose
some
features.
So
if
you
build
note
against
bonuses,
all
works,
but
you
not
all
crypto
futures
world
do
not
all
tell
us.
We
just
work
as
far
as
I
know,
so
that's
some
differences
there,
but
it
should
compile.
D
B
Yeah,
so
it
is
just
issues
all
the
way
around
in
terms
of
like
that
leading
edge.
It's
gonna
be
perfectly
fine
for
quick
to
remain
experimental
for
a
while
and
I
I.
Don't
see
that
as
being
a
challenge,
it's
just
going
to
severely
limit
how
many
folks
can
actually
use
it,
and
so
open
SSL
gates
gets
ya.
B
B
E
E
About
every
every
time
it's
because
the
James
is
using
has
configuration
changes
missed
earlier.
It
regenerates
to
make
files
as
new
to
find
stuff
like
that,
it's
not
so
I,
don't
think.
That's
such
a
big
deal,
I
mean
floating
patches,
isn't
a
concern.
As
jim
says
it's
additive,
it's
not
it's
not
like
it's
digging
in
and
rearranging
the
whole
protocol,
handshake
sequences
or
anything
like
that.
E
There's
kind
of
in
terms
of
the
PR
reviewability
that
is
kind
of
to
two
ways
of
dealing
with
it.
One
we
could
just
flat-out
float
the
patches
as
experimental
knotek's
float
the
patches
immediately
on
node,
but
not
compile
them
in
by
default.
So
they'd
be
they're,
hidden
behind
configure
time
flags,
so
that
would
decrease
the
size
of
the
pull
request
and
be
low
risk.
B
The
the
way
that
you
restructure,
that
with
it,
if
you
look
at
the
PR
right
now
there
are
there
are
two
commits
that
have
to
do
with
the
OpenSSL.
The
update
of
openness,
so
config
is,
is
isolated
in
a
single
commit,
so
you
can,
if
you
filter
the
PR,
so
that
that
is
not
present,
it
gets
much
much
smaller
and
then
all
of
the
the
boringness
is
so
quickly.
If
you
guys
are
in
a
single
commit,
so
those
can
be
looked
at
individually.
E
B
Yeah
so
as
they've
been
going
through
and
and
quick
is
a
work
in
progress,
it's
been
changing.
The
in
one
of
those
is
the
quick
TLS
bet.
So,
as
that
has
been
evolving
as
implementers
have
been
working
on
it,
they
quick
has
been
evolving
its
API
as
well
so
they're
making
that
change,
and
then
the
guy
that's
done.
A
B
A
B
A
Like
the
idea
of
them
not
being
applied
by
default
cuz,
then,
if
say,
for
example,
in
a
security
release,
there
were
some
issues.
We
could
still
ship
those
without
having
to
do
the
merge
and
think
yeah.
We
might.
We
might
break
the
quick
build
option,
but
that's
not
really
that's
something
we
could
fix
up
afterwards.
Probably.
A
B
B
B
E
Yeah,
just
when
a
slightly
time
it's
but
I
mean
I
can
appreciate
this
inspiration
for
about
quicksand,
I,
OpenSSL,
but
I.
Think
it's
worth
bringing
it
open.
Ssl
is
another
process
as
far
as
I
can
see
if
the
largest
rewrite
they've
done
in
the
last
20
years,
like
three
decks.
There's
a
major
change,
there's
tons
of
churn
and
there's
some
pretty
hard
technical
problems
that
they're
trying
to
solve,
and
then
issues
about
configuration.
Redoing,
the
provider
they're,
considering
dropping
the
engine
interface
I
mean
they're.
Their
lofty
goal
was
to
have
a
openness,
l3x
provider.
E
B
B
You
know
something
that
is
experimental.
You
know
similar
to
what
we
do
with
experimental
features
and
there
are
people
willing
to
work
on
it.
So
it
doesn't
that
additional
burden
on
the
folks
that
are
trying
to
figure
out
everything
else
and
the
response
is,
you
know
what
we
got
it
we'll
do
it
later
and
then
they're
being
very
dismissive
of
the
folks
who
are
volunteering
to
do
this
for
them.
So
it's
that
I
think
that's
really
where
the
frustration
comes
in
and
you
know
and
I,
and
you
know,
I'd
make
the
point
in
several
comments.
B
Even
if
they
just
came
back
and
said
hey,
the
timing
is
off.
We
can't
do
it
because
of
timing.
That's
perfectly
valid
all
right
because,
because
the
300
beta
switch
be
out
in
June
and
the
spec
is
not
even
getting
a
go
to,
I
is
G
consideration
in
smell
July.
For
those
who
don't
know,
I
is
the
iesg.
Consideration
is
basically
the
final
step
in
producing
the
end,
the
RFC,
but
at
that
point
the
the
working
group
has
considered
the
spec
done.
B
It's
gone
through
last
call
and
it
needs
to
go
for
that
final
step
right.
The
RFC
itself
would
not
even
be
minted
until
sometime
second
half
up
to
2020,
so
just
on
that
fact
alone,
the
openness
or
so
OMC
is
perfectly
justified
and
saying:
hey.
Your
timing
doesn't
work.
We
can't
any
three
yet,
but
they
could
be
a
lot
friendlier
with
the
community
but
volunteering
to
help
work
on
it
and
that's
not
I.
B
Know
yeah
that's
I
mean
that
that's
the
update,
we're
still
making
progress
on
it.
I
will
do
some
stuff
to
reduce
the
size
of
that
PR
I'll.
Take
it.
Is
it
to
do
to
apply
that
OpenSSL
patches?
Only
if
the
configure
flag
is
is
enabled
right
now,
basically,
what
that's
going
to
mean
is
applying
the
patches
during
build,
rather
than
checking
those
you
know,
there's
any
separate
commits.
B
A
C
Yeah
I,
don't
believe,
there's
much
going
on
still
waiting
on
the
back
port
to
ten
point
X
of
the
instance
data,
so
that
would
sort
of
give
us
a
nice
cutoff
for
an
epi
six
and
then
we
could
start
sort
of
rolling
that,
but
it
does
have
to
land
first
so
that
we
can
have
that
across
all
LTS
versions
and
hopefully
before
he
goes
into
maintenance.
That's
the
biggest
outstanding
issue,
I
believe:
okay,.
A
G
May
make
sense
for
us
to
spin
down
this
initiative
with
EndNote,
unless
people
explicitly
push
back
on
that
there's
an
ongoing
effort
within
the
open
J's
foundation,
where
we've
spun
up
a
standards
group.
That
group
is
in
the
midst
of
trying
to
charter
with
the
CPC
so
that
they
can,
you
know,
be
delegated
authority
over
sending
folks
to
various
standards
organizations
and
help
handle
the
overall
foundation's
engagement
with
standards
says
some
highlights
that
are
worth
knowing
about
it.
Like
the.
G
The
group
is
not
only
looking
at
like
maintaining
existing
relationships
and
works
such
as
stuff
that
the
Jazz
foundation
had
been
doing
in
the
past
with
ECMO,
but
also
exploring
new
standards
bodies
and
organizations
to
join.
So
specifically,
the
Unicode
consortium,
as
well
as
the
OSI,
are
two
organizations
that
were
identified
by
this
group
that
the
foundation
should
join,
and
this
is
now
in
the
board's
core
to
see
through
one
another.
Big
thing:
that's
important
was,
as
we
talked
about
being
chartered
so
that
that
group
can
help
approve.
G
You
know
who
would
go
and
represent
the
standards.
One
of
the
general
sentiments
that
was
raised
was
that,
like
people
did
not
need
to
be
a
member
of
this
group
or
participate
in
that
standards
group
in
order
to
go
and
represent
the
foundation
at
standards
bodies,
that
group
is
meant
to
be
kind
of
like
helping
to
coordinate
the
efforts
and
ensure
that
things
are
consistent.
G
So
with
that
in
mind,
you
know
like
anyone
from
node
who
wanted
to
engage
in
standards
would
be
able
to
either
open
an
issue
over
there
or
approach
someone
from
that
team
and
figure
out
like
how
would
they
go
about
getting
official
approval
to
go?
That
kind
of
context
in
process
is
something
where
we're
currently
drafting
I,
guess,
like
the
the
remaining
bit
here
from
node
side,
would
be
if
there
are
very
particular
things
that
were
interested
in,
engage
as
node,
which
I
do
think,
like
certain
things
with
the.
G
What
working
group
in
particular
was
on
our
radar
I
just
personally,
have
not
had
as
much
time
for
the
engineering
side
of
things,
because
I've
been
very
focused
on
the
strategic
side
of
things,
so
I
guess
kind
of
like
a
hanging
question
to
folks
on
the
TSC.
Is
you
see
value
in
maintaining
this
initiative,
which
I
feel
like
we
have?
We
now
have
a
lot
of
the
infrastructure
in
place
or
in
the
process
of
being
in
place
to
empower
this
kind
of
work.
We
just
would
need
specific
work
that
we
were
chasing
down.
I.
G
A
So
I
I
mean
I'm,
just
thinking
like
if
we,
if
we
haven't,
had
anybody
any
anybody
with
cycles,
there
is
the
effort.
The
other
place,
like
you
suggested
you
know,
maybe
spinning
it
down
for
now
would
make
sense
and
it
that
changes.
If
it's
gonna
change
in
the
near
future,
then
you
know
leaving
it.
There
makes
sense,
but
if
it's
not,
then
maybe
spinning
it
down
until
it
will
would
make
sense.
Yeah.
G
A
A
A
So
thanks
to
my
Aussie,
just
line
up
David,
who
is
from
Google,
who
is
starting
to
engage,
which
is
great
and
tyranny
reached
out
to
me
with
a
few
new
names
for
people
from
Microsoft
who
are
gonna,
have
some
time
to
get
engaged
in
the
build
working
group
as
well,
so
I'm
gonna
get
in
touch
touch
base
with
them
I
think
later
today
and
then
connect
them
to
the
build
working
group.
So
we
are,
you
know,
based
on
our
request
to
the
board,
for
some
help
looks
like
we've
gotten.
A
Some
additional
people
who
are
gonna
be
investing
at
least
on
the
Google
front.
You
know
talked
to
David
sounds
like
it's
definitely
an
ongoing
investment.
So
that's
good
and
you
know
promising
on
the
people
from
Microsoft
as
well.
So
that's
the
update
on
that
front,
any
other
things
people
want
to
mention
or
raise
on
the
current
initiatives.
Strategic
initiatives
front
before
we
close
out
for
today.