►
From YouTube: IETF104-UTA-20190326-1000
Description
UTA meeting session at IETF104
2019/03/26 1000
https://datatracker.ietf.org/meeting/104/proceedings/
B
A
Situation
around
the
is
G
evaluation
of
require
less
drug.
There
are
two
discuss
point
from
security
area
directors
that
work
and
grow
seem
not
to
agree
with.
So
we
have
to
make
some
progress
about
this
and
ten
minutes
open
mic.
That
will
probably
be
replaced
with
another
presentation
if
harness
is
managed
to
be
sometime
here.
So.
D
So
we
have,
as
you
can
see,
we
have
document
review
as
as
Valerie
said,
we
have
a
document
in
last
call
and
then
we
have
a
single
document
in
sort
of
initial
state,
our
our
our
is
DQ
document
recorded
as
we
need
a
little
bit
of
work
there,
but
you
know
we're
comfortable,
we're
I,
think
we're
gonna
sort
of
get
that
done,
and
then
we
have
this
drop
site,
fut
80s
for
free.
Now,
after
that,
as
you
can
see,
there's
nothing.
We've
got
you
know
Hannah's
proposing
some
stuff.
D
We
got
some
other
proposed
documents,
but
none
of
them
have
been
accepted
as
working
your
documents.
Yet
right.
So
at
some
point
some
of
these
may
actually
approached
us
and
say
we
want
to
be
working
with
documents,
but
we're
not
actually
there
yet.
So
this
this
working
group
exists
in
a
perfect
perpetual
state
of
sort
of
almost
done
and
whether
whether
we
actually
get
to
done
anybody's
guess
at
this.
D
F
B
Okay,
yeah,
please
please
switch
lines
for
me.
Okay,
thank
you
very
much.
So,
basically,
the
draft
is
about
duplicating
TLS,
1.0
and
1.1,
based
on
similar
traffic
was
submitted
by
stephan
I
think
it
was
getting
to
Batiatus
working
group,
so
this
one
is
specific
to
email
services.
So
what
I
did
basically
Stephan
and
I?
We
went
through
the
RFC
he
ate
for
one
fall
and
then
replaced
1.7
1.1
we've
wanted
to
ask
minimum,
that's
basically
as
a
recommended
version
so
and
when
I
started
getting
feedback
on
the
draft
itself.
B
So
I've
been
collecting
some
of
us
comments
because
we
changed
the
scope
of
a
draft.
So
one
of
the
first
comment
was
about
addressing
outstanding
errata.
What
was
by
Tim
Fenton?
The
second
is
of
deeper
references
of
a
reference
to
MTA,
STS
and
referred
point,
but
included
was
possibly
include
reference
to
require
TLS,
especially
for
message
submission
and
then
also
got
a
feedback
from
Julian
a
year
saying,
instead
of
using
the
language,
TLS
1.0
and
things
like
that.
B
Just
follow
BCP
195
this
one
I'm,
not
sure
I,
quite
agree
with
a
comment
personally
and
when
there
was
Keith
Moore,
who
included
a
fairly
long
comment.
It
was
about
whether
we
should
encourage
MUA
and
implementation
to
possibly
warn
the
users
about
minimum
confidentiality.
There
was
but
email
services
presently
deploying
email
services
already
provide
all
whether
we
could
have
something
like
even
suppose,
TLS
1.1
1.0.
B
B
So
the
original
aim.
When
writing
the
draft
was
about
TLS
1.0
and
one
for
modification
for
email
services.
My
question
now
is
more
of
a
working
group
of
whether
the
other
points
that
were
mentioned,
a
change
Lascaux
should
be
included
within
the
draft
and,
if
so,
I
would
request
feedback
on
how
to
do
it.
However,
we
should
have
different
internet
draft
to
address
different
issues,
basically
so
without
to
over
my
basic
questions,
but
I
have
four
working.
D
D
So
if
you
started
out
with
a
draft
that
said
all
right
it
just
let's
just
make
two
two
things
historic
and
then
we
have
very
weak
consensus
for
making
a
major
change.
I
think
we
have
to
have
like
clear
consensus
from
the
working
group.
In
that
case,
it's
not
a
problem
right,
but
we
really
need
clear
consensus
on
the
work
from
the
working
group
to
make
a
change
that
like
make
a
make
major
changes
to
work
in
your
document.
I.
E
E
You
know
I
initially
made
the
assumption.
This
only
applies
to
client
to
server
part
because
of
the
document
it's
trying
to
update,
which
was
limited
to
client
to
several
parts.
I'm,
not
saying
it's
wrong
to
update.
You
know
server
to
server,
but
I
think
you
need
to
radical
in
the
state.
You
know
which
way
you
want
to
go
so.
D
E
D
What
I
guess
what
I'm
worried
about
this
chair
in
this
working
group
is
sort
of?
Do
we
have
enough
energy
to
pursue
all
avenues
right
and
and
making
like
making
a
clear
and
concise
scope
for
a
document
like
this
increases
the
chances
that
people
will
review
it
and
actually
have
like
consistent
opinions
about
it
right?
Otherwise,
we
risk
winding
up
with
a
document
with
a
lot
of
text.
Nobody
reviewed
it
I.
E
E
D
Right
in
that
case,
what
I
think
we
I
would
like
to
give
you
some
some
some,
like
guidance
looking
on,
if
I
try
to
like
slice
up
your
comments
into
two
pies
right,
this
stuff
that
you
consider
to
be
like
non-controversial,
slash
editorial
right,
you
can
I
think
you
sort
of
make
a
new
version
with
that,
and
then
you
do
a
single
post
for
each
other
issue
and
we'll
have
have
we'll
try
to
get
consensus
of
each
on
each
of
them
right.
But
you
know
we're.
D
D
D
Yeah
there
is
the
same
issue
yeah
right,
so
so
that's
that's
one
of
the
comments.
That's
one
of
the
threads,
so
it's
actually
a
little
bit
difficult
to
display
these
things
in
the
room.
I
I
think
we
have
to
rely
on
people
being
up
to
speed
on
this,
but
it's
like
you,
so
anybody
have
I
think
they
want
to
talk
about
around
any
of
these
issues.
D
I
think
we
have
five
more
minutes,
maybe
to
spend
on
this,
and
then
we
we
have
to
move
on
otherwise,
I
think
Loganlea
new
is
like
try
to
try
to
get
consensus.
We
try
to
push
for
consensus
on
each
of
these
things
individually,
but
apply
them
only
as
as
we
reach
consensus
and
if
you're
unsure
about
that
just
reach
out
to
the
chairs
and
sort
of
will
help
you
like
push
on
the
word.
The
mailing
list
I
get
to
consensus
or
not.
B
A
H
H
Is
we
and
actually
I
like
this
change,
because
it
had
made
the
the
draft
a
little
bit
hard
to
read,
because
we
had
both
an
SMTP
extension
called
require
TLS,
which
I
put
in
all
capital
letters,
and
we
had
a
header
field
called
require
TLS,
which
I
put
in
mixed
case,
and
if
people
didn't
notice
the
cases
it
was
a
little
bit
hard
to
follow.
So
there
was
a
suggestion
in
IES.
H
You
review
that
we
make
the
header
field
declarative
rather
than
an
imperative,
so
that
makes
it
TLS
required
and,
of
course,
there's
a
hyphen
there,
because
header
fields
can
have
embedded
spaces
in
their
names.
So
I'm
planning
on
changing
the
the
name
of
the
of
the
header
field
from
require
TLS
to
TLS
required,
still
takes
one
mandatory
argument,
which
is
no.
H
There
was
some
some
language
in
there
about
bounce
messages
and
it
was
sort
of
complicated
and
perhaps
a
little
bit
confusing
in
terms
of
whether,
whether
it
bounced,
whether
you
paid
attention
to
require
TLS
for
a
bounce
message
or
really
any
message
for
which
the
mail
from
address
was
null,
and
we
decided
that
there
was
no
longer
a
need
to
do
that.
If
you
were
sending
a
bounce
message
and
you
wanted
and
you
didn't
want-
require
TLS
on
it,
you
just
didn't
specify
it.
H
You
didn't
there
wasn't
that
a
special
rule
there
I
have
yet
to
write
a
better
description
of
Arya
janae
tadeas,
the
the
the
draft
currently
describes,
basically
just
mailing
lists
as
one
of
the
situations
where
a
message
is
received
that
might
be
received
with
required,
TLS
and
in
and
it
originates
a
new
message
and
talks
about
the
situations
that
you
know.
The
mailing
list
might
really
want
to
I.
Forget
the
exact
wording
faking
it
here,
but
that
the
mailing
list
might
want
to
turn
on
require
TLS
for
the
message
that
it
originates
as
well.
H
But
it
was
pointed
out
in
iesg
review
that
there
are
a
lot
of
other
situations
besides
mailing
lists
where
messages
re
originated.
Vacation
messages,
for
example,
that
come
back
is,
is
one
and
that
one
may
be
a
little
bit
tricky,
because
that
one
has
to
do
with
basically
a
user
program
that
gets
executed
that
might
not
have
visibility
into
the
require
TLS
status
of
the
incoming
message.
H
Siv
is
another
example.
Where
see,
if
can
cause
messages
to
be
originated
as
a
result,
so
not
just
mailing
lists
there,
so
I
need
some
I
need
to
come
up
with
and
socialize
some
new
language.
Yet
on
these,
these
sorts
of
messages
that
that
happen
as
a
result
of
a
message
that
might
have
required
TLS
on
it
and
Barry
standing
up
that
Barry
is
standing
up
and
Barry
is
speaking.
C
Perhaps
this
has
been
discussed
and
I
haven't
been
following
the
discussion
very
closely,
but
the
bounce
messages
bother
me
a
little
bit
because
sometimes
bounce
messages
are
just
saying.
Your
message
didn't
get
delivered
and
has
have
reason
headers
and
stuff,
but
sometimes
they
include
the
message
right.
Some
of
them
include
the
full
message,
even
if
they
include
the
headers,
not
using
TLS
is
exposing
those,
but
especially
if
they
include
the
full
message.
We
have
that
issue
and,
as
you
said,
SIV
redirect
is
a
is
a
big
thing.
H
H
C
C
There
are
some
implementations
of
Civet
are
entirely
client-side
and
the
client
side
decides
what
to
do
with
the
message,
and
you
can't
really
do
anything
about
that.
But
if
the
SIV
script
simply
tells
the
server
what
to
do,
then
we
I
think
we
should
say
that
the
server
must
propagate
the
required
TLS
state
to
the
results
of
the
subscribers
I'm.
H
H
E
C
E
H
And-
and
it's
true
and
so
you
know
within
while
you're
an
SMTP
for
choir
TLS
can
determine
if
the
receiving
agent
is
is
implementing,
require
TLS
and
that
send
it
the
message
if
it
isn't
and
that
so
so
that's
handled,
but
once
it
gets
once
it
once
it
gets
passed
to
some
sort
of
a
user
agent.
Then
all
bets
are
off.
G
H
H
It's
like
Oh,
forgetting
I,
have
a
clicker
okay.
So
one
thing
that
that
the
the
chairs
and
I
had
discussed-
and
you
know
there
is
there-
is
some
concern
about
the
TLS
required
new
name
header
field
that
you,
you
know
that.
Basically,
the
goal
here
is
for
TLS
required
to
provide
an
exception
to
policy
mechanisms
that
might
be
advertised
by
the
recipient,
like
by
Dane
and
by
MTA
STS.
And
you
know
there
are
a
couple
different
ways
of
looking.
H
At
those
exception
mechanisms
I
tend
to
look
at
them
as
sort
of
an
advertisement
that
sort
of
says.
When
you
connect
to
this
server,
you
should
expect
that
we
can
do
that.
We're
doing
TLS
you
and
you
should
expect
to
be
able
to
negotiate
start
TLS,
and
you
know
perhaps
even
tell
you
what
what
the
certificates
look
like
there
in
the
case
of
Dane,
especially
and
so
and
I,
think
there's
a
couple
a
couple
of
different
viewpoints
about
how
how
much
of
her
requirement.
H
That
is
what
what
this
this
proposed
new
section
for
the
security
consideration
is,
is
basically
to
document
the
fact
that
yes,
we're
asking
for
an
exception
to
what
Dane
and
him
and
MTA
STS
are
suggesting
encouraging
/,
not
exactly
mandating,
because
they
do
still
accept
messages
generally,
that
don't
have
require
the
the
don't
have
a
start.
Tls
turned
on.
That
would
be
a
different
mechanism.
They
it's
perfectly
okay
for
them
to
just
plain,
refuse
to
accept
messages
unless
you've
negotiated
start
TLS
first,
they
typically
don't
do
that.
So
so!
H
Because
of
that,
it's
that's
why
I
kind
of
say
it's
an
encouragement
rather
than
a
requirement,
and
so
the
idea
of
TLS
required
no
is
to
allow
messages
through,
for
example,
to
tell
the
administrator
that
hey
you've
got
a
miss
configuration
if
hey
you've
got
a
miss
configuration.
So
this
paragraph
is
just
a
first
draft,
that
of
something
that
we
might
say
about
that
in
the
security
considerations,
at
least
to
get
that
out
in
the
open.
This.
C
Error
in
this
is
TLS
required.
No
header
field
represents
an
explicit
decision
on
the
part
of
the
sender
not
to
require
TLS,
not
yes,
use
TLS,
so
that
needs
to
be
fixed.
That
is
correct,
but
the
other
thing
is,
of
course,
that
there's
a
conflict
between
saying
TOS
required
no
on
Sundaram
and
simply
having
and
well
on,
MTA
STL,
so
is
having
a
server
that
will
not
talk
to
you.
If
you
don't
negotiate
right.
C
C
Say
something
about
that
too,
that
there's
the
results
of
this?
This
is
a
different
kind
of
negotiation
and
you're
going
to
get
an
end
result
that
is
either
okay.
I'll
talk
to
you,
even
though
you
didn't
use
TLS,
but
I,
don't
like
it
to
simply
a
refusal
to
communicate,
and
that
should
probably
be
it
be
mentioned
here,
because
you
say
it's
expected
that
this
directive
will
generally
be
followed
and
I.
Think
that's
a
little
too
strong
yeah.
G
G
I
H
J
J
B
H
Yeah,
well,
the
the
the
positive,
the
the
the
positive
way
of
saying,
TLS
required.
We
do
through
a
through
the
SMTP
extension,
of
course,
instead
and
and
there's
a
reason
for
that
is
because
you
you
can
actually
you
go,
you
want
to
make
sure
that
you've
got
a
continuous
chain
and
so
doing
that
in
the
SMTP
in
the
SMTP
path
is,
is
the
right
place
to
do
it?
K
Jos
Alawite
tableau,
I,
think
you
know
with
respect
to
if
TLS
required
is
no
as
long
as
it's
I
think
it
would
be
unfortunate
if
a
server
that
you
know
had
to
respect
that
and
say
Paul
I'm,
not
community,
less
because
they
said
no.
The
server
may
have
a
policy
to
enforce
to
us
so
and
I'm
the
way
this
is
worded
I'm,
not
clear.
Yeah.
H
And
so
so,
I
think
Barry
pointed
out
the
the
wording
error
here,
which
is
decision
not
to
use
to
us.
It's
it's
a
decision
not
to
require
TLS.
You
can
still
use
to
us.
We
encourage
people
to
use
TLS.
It's
just
that.
If
there's
something
that
saying
you
gotta
use,
you
know
we
really
want
you
to
use
TLS
or
something
like
that.
You
are.
You
have
more
freedom
to
ignore
that
and
I
think
the
last
sentence
may
be
problematic.
C
C
L
Think
just
mostly
made
my
point,
which
is,
it
seems
some
folks
aren't
catching
that
require
TLS,
no
isn't
required,
no
TLS,
and
so
it's
as
interoperable
as
as
mail
is
today
for
agents
who
have
no
special
policy,
neither
support
for
Dane
nor
support
for
MPs
STS,
but
are
still
capable
of
doing
opportunistic
TLS
and
do
it
92
to
93
percent
of
the
time.
If
we
look
at
the
Gmail
statistics
right,
the
bulk
of
internet
email,
actually
more
than
the
way
in
fact
by
a
good
margin,
is
actually
using
TLS.
L
It's
just
not
authenticating
and
not
required,
so
require
TLS
know
is
not
the
same
as
require
know.
Tls
the
words
don't
quite
commute,
and
maybe
that
can
be
even
clearer,
I
think
we're
trying
to
make
it
clear,
but
in
the
room
that
still
seems
to
be
an
assumption
that
if
a
server
requires
TLS
somehow
this
won't
interrupt.
But
it
absolutely
will
what
the
server
won't
know
and
can't
know
is
whether
its
certificate
got
checked.
I
Then
connect
again
with
respect
to
Victor's
point
I'm,
pretty
sure
I'm,
not
one
of
the
people.
That's
confused
about
this
and
then
getting
back
to
the
sort
of
last
sentence
on
the
slide
and
and
very
suggestion,
I
think
it's
a
little
bit
more
subtle
than
just
saying
that
TLS
required
is
the
more
fine-grained
mechanism.
I
Yes,
it's
fine-grained
in
that
it's
a
per
message
level,
but
it's
also
sender,
preference
and
you
know
the
day
an
MP
STS,
our
recipient
preference
and
yes,
they
are
more
coarse-grained,
but
it's
sort
of
a
trade-off
or
a
tussle
between.
Do
we
honor
the
sender,
preference
are
doing
honor,
the
recipient
preference-
and
you
know-
maybe
we
can't
really
mandate
one
over
the
other,
but
you
know
they're
in
conflict
and
they're
sort
of
from
qualitatively
different
spaces
and
yeah.
That's
like
a
hard,
hard
question
to
have.
C
C
Still
do
that
I'm
looking
at
a
sent
message:
hey
Victor!
If
I'm
looking
at
a
sent
message
that
says
I
don't
want
to
require
TLS
and
a
recipient
that
says,
I
do
I
would
not
say
well,
I'll
believe
the
sender,
because
it's
a
per
message,
fine-grain
thing
I,
would
say:
I'm
gonna
use
TLS,
because
the
recipient
wants
to
use
it,
and
this
could
be
because
the
recipient
knows
they're
being
monitored
by
the
government
or
something
like
that.
Well,.
C
Yes,
definitely
is
saying:
I
require
TLS,
that's
what
strict
means
in
that.
So,
but
what
they're
saying
is
it's
the
the
sender
is
saying:
maybe
I
support
TLS,
but
I
don't
want
to
require
it
for
this
message
and
the
recipient
is
saying:
I
require
TLS
for
everybody
who
connects
to
me
and
the
result
is
you
have
to
use
TLS
so.
H
M
L
So
the
word
strict
in
Mt
STS
is
only
there
by
analogy
with
HSTs,
and
the
analogy
is
far
from
from
accurate
in
many
ways,
and
indeed
there
is
no
actual
requirement
to
use
TLS
in
Mt
SDS
for
senders
who
do
who
are
not
currently
employing
MTS
TSM
tsts
defines
how
to
follow
all
of
the
precepts
and
laws
of
of
TLS
for
senders
who
are
playing
the
game.
What
this
specification
does
is
allow
a
sender
to
act
as
a
sender
who
is
not
playing
the
game.
L
Mt
STS
does
not
mandate
the
use
of
TLS
by
all
senders
or
who
are
doing
email.
It
cannot
does
not
do
that
and
I
think
that
was
clear
in
some
of
the
mailing
list
discussion.
There
is
no
generally
in
the
DRA.
You
know
you
must
do
this
if
you
support
MTA
SDS
generally,
the
spec
quite
clearly
says
if
you're
doing
MTA
SDS.
This
is
how
you
must
do
it,
but
there's
an
if
and
it's
qualified.
L
D
L
M
Need
to
get
on
with
this
Pete
Resnick
I
I
find
what
I'm
going
to
say
stupid,
but
I'm
gonna
say
it
anyway,
that
there
there
is
no
conflict.
Obviously
we
all
know
between
TLS
required
no
and
I'm,
requiring
TLS
by
the
recipient,
and
maybe
this
is
some
semantics
goofiness
that
people
just
are
getting
wrapped
around
the
name
of
the
header
and
call
it
TLS
optional.
Yes,
and
people
will
be
fine.
I
I
find
the
whole
thing
goofy
that
people
are
even
having
this
discussion.
So
if,
if
that
wording
is
confusing,
people
switch
the
name.
D
On
so
you
know
note
the
fact
that
we're
talking
about
security
considerations-
this
is
not
necessarily
normative
language
right,
so
we're
just
giving
guidance
to
implementers
right.
So
I
I
think
you
know,
let's
consider
word
smithing
this
on
the
list.
I
assume
you're,
gonna
post
this
to
the
list,
and
we
can.
L
The
last
thing
I
want
to
say
is
that
we
should
all
remember
that
that
email
is
basically
a
large
T
UDP
Datagram
carried
over
TCP.
It's
a
one-way
message
from
the
sender,
with
all
of
the
issues
that
that
carries,
and
so
the
sender
knows,
far
more
about
the
context
than
any
recipient.
The
sender's
already
implement
all
kinds
of
policy
based
on
message,
content
in
terms
of
message,
routing
and
selection
of
gateways,
and
so
on
and
selecting
a
policy
that
user
doesn't
use.
D
Victor
and
I
think
that
the
trick
here
is
is
to
get
all
of
those
all
of
that
wisdom
into
you
know
condensed
into
the
security
consideration
section,
so
we
can
get
past
the
AIC,
so
I
think
in
the
end,
Victor
you're,
the
record
here.
You
spent
a
lot
of
time
right
on
that
thread,
trying
to
sort
of
get
this
message
across
and
we
just
need
to
put
this
in
text.
So
you
know
appreciate
all
out
all
right.
That
puts
us
at
I.
F
N
So
I
submitted
a
test
hi.
This
is
Hannes.
I
submitted
the
document
to
the
group
to
the
loot.
That
group
and
the
background
is
to
following
a
while
ago
years
ago,
I
was
working
with
Thomas
for
sáááty
and
and
others
in
the
dice
working
group
to
define
a
profile
for
TLS
and
DTLS
1.2
for
use
in
IOT
environments
and
it,
as
you
know,
TLS
1.2
and
DTLS
1.3
I
wanted
to.
There
were
lots
of
extensions
and
some
of
them.
If
you
use
them
incorrectly,
they
didn't
lead
them
to
the
desired
results
and
also
for
IOT.
N
N
However,
it
leaves
two
aspects
to
profiles,
namely
one
is
one
is
the
choice
of
algorithms.
It
makes
an
default
algorithm
choice
which
is
great
for
the
web,
and
the
other
thing
is.
It
also
requires
a
profile
that
describes
on
what
protocol
you
application
protocol
you
use
TLS
and
DTLS
103
with
for
use
of
the
zero
RDD
functionality
and
guys
have
worked
in
on
such
a
profile
for
HTTP
usage,
I
think
that's
whatever
group
doesn't
matter
and
in
this
document,
I'm
actually
putting
those
two
functions
in
India.
N
Currently,
there's
not
much
else.
Besides
that
ambition
in
the
future,
as
we
gain
more
experience
with
implementations
in
the
IOT
field,
will
provide
additionally
some
guidance
on
how
to
use
certain
features
in
an
IOT
context
to
provide
better
flash
optimization
over
the
over
the
air
band
production
are
also
sort
of
to
lower
RAM
usage.
N
So
that's
that
that's
the
purpose
of
the
document.
That's
why
I
submitted
it
to
this
group.
The
dice
group
doesn't
exist
anymore,
otherwise,
I
would
have
sent
it
here,
but
I
think
this
group
is
it's
also
good
for
that
purpose,
because
there
was
this
prior
work
on
the
best
current
practices
for
TLS
1.2
and
the
algorithms
that
came
along
with
it.
So
I
think
if
it
fits
nicely
in
here,
although
the
IAD
communities
and
yet
here
but
I,
think
there
can
be
trust
sort
of
working
group
postings.
N
So
so
that's
that
was
the
intention
and
are
you
looking
for
this
to
be
a
working
document
yeah
that
would
be
nice
and
to
find
some
reviewers
in
this
in
this
group
or
in
other
in
general.
Some
reviewers
I
can
obviously
target
some
individuals
who
are
know
who
are
working
on
this
with
so
we're
currently
wrapping
up
DTLS,
1.3
and
sort
of
TLS.
As
you
know,
1.3
has
been
finalized,
but
it's
still,
its
usage
in
an
iud
environment
is
still
early
days
because
it
takes
a
little
bit
longer
to
write
these
embedded.
N
D
One
problem
I
mean
we
might
have.
Is
that
sort
of
the
people
in
this
room
or
typically
expect
to
see
these
things
related
to
tui
maker
entree,
because
that's
sort
of
what
the
work
where
the
working
group
is
now
I?
Think
in
order
to
like
make
us
successful
like
import
of
this
document,
we
got
to
have
like
the
the
right
reviewers
and
the
right
people
in
the
room,
so
I
think
what
would
help
is
if
you
could
help
us
find
reviewers
who
could
actually
turn
up
on
the
on
the
mailing
list.