►
From YouTube: IETF92-UTA-20150323-1520
Description
UTA meeting session at IETF92
2015/03/23 1520
A
A
A
A
C
A
D
D
C
B
A
A
A
A
B
A
B
This,
for
those
who
may
not
be
a
wise,
is
UTA,
flts
or
dog,
and
our
agenda
is
we're
going
to
spend
a
couple
of
minutes
on
on
them,
status,
update
and
and
and
a
young
russian,
but
not
too
much
so
since
we
met
last,
we
have
actually
graduated
progress.
Will
progress
the
couple
of
regiments?
We
have
our
first
document
published
analysis
or
since
74
57
used
to
be
eg,
a
FF
draft
is
all
done.
B
B
A
Just
posted
0
2,
as
you
asked,
which
finish
unterminated
sentence
x,
I'm,
but
the
may
change
in
01
was
splitting.
Instead
of
you
know,
having
requirements
and
no
different
type
of
actors
like
mail,
user,
client,
writers
on
ce
certificate,
authorities,
cetera
in
one
section,
I
split
them
in
two
separate
sections,
and
this
actually
caught.
C
A
B
So,
let's
get
a
quick,
sensitive
read
this
draft
okay,
so
many
of
you
guys
say
anything
about
your
having
been
real
draft
on
the
money
list.
It's
something
we
could
just
sort
of
pipe
up
in
the
list
say
yes,
I
read
it.
It
looks.
Okay,
see
that
I
issue
allocated
blast
coil
in
the
next
couple
of
weeks,
but
we
really
have
to
get
one
or
two
more.
Yes,
I
whether
it
looks
okay
reviews
it
doesn't.
B
A
D
Okay,
I
think
we
have
microphone
now.
Okay,
I
did
a
revision
of
the
draft.
It's
now
a
working
group
draft,
so
so
this
is
just
the
overview
of
what's
in
the
draft
for
people
who
are
part
of
our
spectators
and
haven't
read
it
and
if
you
haven't
read
it
yet
I'd
really
like
you
to
read
it
because
I
want
to
get
this
done
relatively
soon,
but
this
is
the
overview
of
what's
in
the
draft.
D
Basically,
it's
a
set
of
things
with
the
intent
of
improving
confidentiality
for
the
link
between
the
mail
user
agent
and
the
server.
This
is
not
about
mpa
mkay
relay.
That's
that's
out
of
scope
for
this
document,
so
this
is
the
basic
overview.
Moving
on
the
changes
I
made
to
this
revision
I,
I
believe
technical
contents
largely
complete.
D
We
renamed
the
privacy
assurance
to
confidentiality
assurance
and
based
on
Russ's
review.
I
need
to
do
a
little
more
wordsmithing
about
that,
because
that
is
the
correct
terminology
for
what
this
is:
providing
and
Irene
a
privacy
assurance
to
no
privacy
insurance,
as
I
did
no
confidentiality
assurance
because
I
think
that
looks
better
other
words
the
sniffing.
It's
now
a
working
group
draft
and
I
fold
it
in
a
bunch
of
review
comments
from
my
co-author
Keith.
D
So
to
do
I
need
to
fall
fold
in
the
comments
that
Russ
made.
I
just
I
read
all
of
them,
so
I'll
just
make
them
yell
unless
there
are
further
comments
on
that
on
those
topics
and
I
need
to
add
an
explicit
reference
to
the
pls
bcp.
So
those
are
the
two
items
that
I
definitely
have
and
I'm
a
mitt
and
I'm
also
inclined
do
a
pass
over
to
see
if
it
can
improve
readability
and
approachability
of
the
draft
a
little
bit
moving
on
to
the
next
slide.
So
the
old
issues.
D
So
one
of
the
open
issues
I
have
an
item
to
go.
Gather
deployment,
data
on
port
465
versus
587
and
I
haven't
had
time
to
gather
that
data.
Yet
so,
basically,
right
now
the
document
is
recommending
port
465
over
587.
The
recommendation
that
ends
up
in
the
final
document
should
be
backed
by
what's
actually
deployed
and
I
want
to
understand
the
relative
deployment
of
port
465
versus
587,
because
yo,
if
we
go
with
port
465
there
are,
there
are
process
issues
that
make
that
that
are
challenging.
D
So
if,
if
it's
the
case
that
port
five
days
at
every
isp
that
offers
port
465
also
offers
port
587,
then
I
think
we
should
just
go
with
port
587
to
avoid
the
process
difficulties.
But
we
need
to
gather
that
data,
so
it
does.
Anybody
have
cycles
to
gather
data
on
like
significant
ISPs
and
clients,
support
for
these
ports,
guessing
not
I,
guess
that
stays
on
my
plate
and
they'll
try
to
get
it
done
as
soon
as
possible.
D
The
next
open
issue-
this
is
one
that
came
up
in
a
discussion,
Keith
and
I
were
having-
and
I
wanted
to
I
take
this.
This
is
a
really
interesting
one
for
for
the
group
to
discuss.
There's
a
design
trade-off
in
here
where
the
current
spect
the
way
it's
written.
If
you
have
a
no
confidentiality
assurance
account
set
up,
and
it's
not
using
TLS
on
that
on
those
connections
and
then
suddenly
the
server
says
wait
a
minute
I'm
now
offering
TLS.
D
There
is
a
model
that
the
current
approach
would
I
will
try
to
use
TLS
if
it
uses
it.
If
it
can
use
it,
even
though
the
cert
doesn't
verify
it
will
it
will
latch
on
TLS
so
that
it
will
keep
using
TLS.
So
the
idea
is
you
get
confidential
yo
if,
if
the
site
wasn't
using
TLS
and
then
starts
offering
it,
but
without
a
valid
sir
it'll
at
least
get
the
passive
protection.
D
So
that's
how
the
current
drafts
written
the
downside
to
this
approach
is
there's
an
obvious
denial
of
service
attack
of
your
Joe
asp
with
no
ssl,
and
I
insert
a
man
middle
and
say:
hey
I'm,
offering
SSL
now
I
want
you
to
latch
it
on,
and
then
the
quiet
latches
it
on
and
now
you
can't
connect
your
ISP
anymore,
so
there's
a
denial
of
service
attack
against
the
client
with
the
model.
That's
currently
in
the
draft.
D
The
other
approach
is
sorry,
if
the
certain,
if
the
certain
doesn't
validate,
we
can't
latch
on
SSL
and
so
we'll
just
do
it
in
the
clear
yeah.
Well,
you're
you're,
all
your
data
will
go
in
the
clear
on
that.
No
confidentiality
assurance
connections,
so
that
would
solve
that
one
denial
of
service
attack,
but
you
lose
you
lose
passive
confidentiality
protection.
D
A
D
D
I've
had
some
open
issues
for
a
while,
where
I,
where,
if
someone
contributes
text
I'd,
be
I'd,
be
interested
in
possibly
filling
that
text
in
so
for
the
service
setup.
Part
of
the
document
I've
got
I
I
explain
how
to
use
the
existing
SRV
set
up
to
do
a
count
set
up
and
there
there
is
a
way
to
extend
that
to
leverage
Dane
and
if
somebody
added
provided
text
for
me
to
add
to
the
document
to
do
that,
I
would
most
likely
be
supportive
of
adding
that
text.
C
D
C
D
Account
setup
works
as
you
look
at
the
SRV
record
only
once
and
you
don't
generally
don't
look
at
it
again
so
these.
So
that's
why
the
HST
s
style
account
indicator
is
in
the
protocol
with
with
this
draft.
It's
not
you
know
it's
dead
done
in
the
protocol.
The
same
way
it's
done
in
HD
hit
p,
but
you
know
map
to
the
email
model.
So
no
we're
not
where
I
I
did
not
think
of
doing
a
chest.
Es
approach
in
using
the
DNS
cuz.
D
E
D
You
write:
have
you
read
the
draft?
No,
no
I
would
I.
Please
do
read
the
draft
and
you
know
and
section
8
has
the
discussion
of
the
SRV
yellow
account
setup
model
in
the
draft,
and
it
has
some
discussion
of
advertising
SSL
in
there,
and
the
documented
references
also
has
discussion
of
that.
So
occasionally
that
see
if
it
meets
your
needs
and
if
not
it
yo,
let
let's
see
some
suggestions
for
text
improve
the
document.
I
appreciate
that
thanks.
A
David
lump
under
stand
on
your
answer:
I.
Don't
think
they
can
currently
indicate
that
there
must
be
a
zazzle
available.
I
think
it
can
only
refer
to
the
certificate
to
be
used
and
authenticate
that,
but
that's
that's
a
bit.
That's
missing
from
Dana
and
I
think
that
needs
to
be
added,
so
I
kind
of
support.
The
question
and
I
think
someone
wants
to
go
today
and
at
that
as
a
separate
capability.
But
it's
not
there
as
far
as
in
hell,
yeah.
E
Think
I,
guess
you
know
my
feeling
is.
If
we
get
a
reliable
indication
from
the
server
that
it
now
supports
pls
and
will
continue
to
do
so,
then
it's
reasonable
to
trust
that
and
reliable
means
that
it's
coming
over
a
TLS
encrypted
and
authenticated
connection
with
a
certificate
that
we
trust
and
that
we
have
we
sort
of
trust,
axiomatically
and
the
question
I
have
is:
how
do
we
know
when
that's
good
enough
for
that
purpose
and
I?
Don't
know
that
I
have
the
answer
because
they're
this
sort
of
lots
of
little
corner
cases
there.
D
Thinking
about
that
well,
I
mean
I.
I
think
that
case
is
not
controversial
yo.
If,
if
you
can
validate
the
server
cert
and
the
search
says
I
support
pls
with
cert
validation
in
the
session,
you
latch
it
on
your
done.
I
think
that's
already
covered
at
the
current
test.
The
part
that
I,
I
think
is
open
to
change
is
the
part
where
okay,
I
I've
been
talking
to
the
account.
There's,
there's
been
no
TLS
at
all.
All
of
a
sudden
see.
D
Ok,
I
can
now
do
TLS
with
the
server
and
the
server
I
can't
very
validate
the
sir.
The
cert
doesn't
validate,
but
I
can
get
an
encrypted
cut
so
that
I
have
at
least
passive
confidentiality
and
then
the
server
says
by
the
way
I
I
am
do
I
am
offering
TLS,
but
not
offering
cert
valid
certs
and
I'm
doing
this
indefinitely.
D
So
the
question
is:
when
that
scenario
happens,
should
the
client
latch
on
and
insist
on,
TLS
in
the
future,
even
though
the
cert
doesn't
validate
or
should
the
client
just
use
it
for
that
session
and
then
the
next
time?
If
there's
no
TLS,
sorry,
you
get
no
confidentiality.
Those
are
the
two
options,
I
think
it's
a
really
interesting
question.
A
D
C
It's
the
opportunistic
case,
and
the
answer
is
next
time
you
arrive
wherever,
because
you
can't
tell
who
you've
been
talking
to
the
next
time
you
arrive.
If
it's
clear
text
only
and
TLS
is
not
available.
Maybe
you
were
talking
to
something
bad
actor
last
already
got
the
TLS.
I
will
just
continue
to
do
the
opportunistic,
though
of
if
the
TOS
is
available
use
it
not
don't
don't
latch,
because
you
don't
know
who
the
bad
actor
in
this
play
is
that
clear
text
I
or
the
TLS
die.
D
I,
you
know
that's
the
argument
for
that
side,
so
I'll
make
the
argument
for
the
other
approach.
The
other
coach
is
I
yo.
If
my
service
provider
can't
you
know,
for
some
reason,
can
try,
sir,
but
he
can
get
TLS
on
the
server.
I
would
rather
have
passive
confidentiality
than
in
the
clear,
and
you
know
an
active
attacker
can
always
get
me
so
so
that's
fine
and
so
I'd.
D
Actually,
you
know,
and
in
the
case
where
active
attacker
starts,
yo
pretending
to
be
the
sober
and
saying
I
want
you
to
I,
want
you
to
turn
on
TLS
and
require
it
I'm,
actually,
okay,
with
a
dial
of
service
attack,
because
the
customer
will
call
the
isp
and
say
why
don't
I
have
writer
hype,
I
have
any
confidentiality
all
of
a
sudden,
and
so
I
write
the
pressure
on
the
ISPs
too
young
to
roll
out
proper
encryption
that
that
introduces.
So
that's
that's
sort
of
the
the
trade
up.
A
E
Keep
more
again,
I
think
one
of
the
things
that
occurs
to
me,
I
think
app
insert
is
a
trusted
certain
that
it's
axiomatic
Lee
trusted
just
as
much
as
one
from
a
trusted
signed
by
trusted.
Ca
yeah.
I
think
if
you
get
a
latch
declaration
from
the
server
that
says,
we
support
this
feature
from
a
pin,
search
that
you
should
trust
that
equally,
as
you
trust
one
whatever.
E
It's
like
well.
Let's
just
revert
to
the
behavior
because
it
will
probably
be
there
supported
in
the
user
agent
and
it
doesn't
cause
the
support
calls
so
one
way
or
another
I
think
that's
what
tends
to
happen
so
I'd
rather
I
would
actually
own
balance
rather
not
trust.
It
I
also
think
it's
simpler.
That
way,
it's
easy
to
describe
in
a
way
that's
likely
be
implemented
correctly.
A
A
A
D
A
C
D
B
B
D
E
Say
I
think
the
main
danger
of
the
thing
that
you
want
is
you
want
to
upgrade
to
confidentiality
when
you
can,
but
you
also
want
to
minimize
the
number
of
support
calls
that
result
from
this
neck
admit.
So
that's
the
trade
off
a
few
like
that
anything,
that's
kind
of
hard
for
support
people
to
predict
like
here's,
the
timer
going
off
on
this
laptop
or
whatever
I
feel
like
that,
actually
makes
a
support
situation
worse
and
yeah
I
would
lean
against
it.
For
that
reason,
so
that's
permalink.
B
D
D
B
B
D
A
D
D
Discharges
you
mentioned
HST
s,
yes,
there's
models
of
that.
You
know
similar
model
there's
a
section
on
using
cell
signed
cert
in
conjunction
with
hsps
and
RFC
6
7
97,
which
basically
says
you
got
to
distribute
route
certs
to
your
users
boxes
because
we
kill
the
connection.
If
it's
unauthenticated,
okay,
I'll,
go,
read
that
text
and
add
and
see.
If,
if
there's
something,
I
can
pick
up
and
adapt
as
part
of
this
change,
the.
C
D
D
This
is
mandatory
to
implement
for
interoperability.
The
current
text
I
have
in
this
draft
says
you
know
we're
not
changing
that
it's
mandatory
to
implement,
but
you
can
turn
it
off
by
default
in
I.
Should
I
be
stronger
about
getting
about
changing
that
as
in
should
I,
say.
Ok,
the
I
maps
back
has
now
changed
that
cipher
suite
is
no
longer
mandatory
to
implement
the
Nana
Tori
to
implement
fri
map
is
now
the
tls
12
cipher.
The
bcp
recommends.
B
A
A
D
D
D
C
Is
people
a
recommendation
from
the
security
folk
is?
The
other
choice
is
to
go
in
the
other
direction
and
say
you
dereference,
whatever
TLS
says
to
be
that's
what
you
want
to
do,
and
so
they
get
out
of
line
now,
specifically
and
say:
what's
man
for
you,
it
is
written
over
there
don't
look
over
there.
Does
that
make
sense,
I
meant
actually
activities
to
say
it's
mandatory
with
this
particular
cipher
suite.
C
B
A
D
A
B
E
D
So
these
so
you're
saying
the
data
is
that
anybody
who
has
465
also
has
587
yes
with
start
TLS.
Yes,
if
that
is
what
you're
saying
that
suggests,
data
supports
a
a
change
in
the
draft
yo,
and
so
one
of
the
reasons
the
draft
has
written.
The
current
way
is
its
kind
of
architectural,
II
Queen
to
say
yo
for
imap
pop
and
submit.
We
prefer
the
separate
court
because
that's
deployed,
but
what
we're
going
to
have
to
what
I'm
going
to
have
to
change
to
is
prime
F
and
pop.
D
We
prefer
the
separate
port,
because
if
you
survey
the
providers,
the
separate
court,
I'm,
f
and
pop
that
yo
anytime,
my
map
start
TLS
and
pop
star
TLS
are
available.
Two
separate
court
is
also
available,
but
the
other
is
not
true.
You
can
find
providers
with
a
separate
court,
but
not
start
healing
what
and
significant
you
know.
But
if
the
opposite
is
true
of
SMD
p
suggestion,
then
then,
then
it
makes
the
spec
more
more
complicated
to
write
number
strictly.
Don't,
although.
A
D
D
B
E
There
were
more
reasons
besides
just
deployment,
that
a
separate
court
seemed
to
make
more
sense
and
I
say
that
is
the
the
inventor
of
stock
pls,
but
I,
don't
necessarily
recall
what
they
were.
I
feel
like
the
issue
with
a
separate
quarters.
Originally,
if
you
try
to
sort
of
do
opportunistic
upgrades,
you've
got
some
vulnerabilities
there,
but
is
long
as
you
have
things
latched,
then
I
think
the
separate
port
is
actually
better.
E
D
Yeah
there's
some
controversy
because
I
heard
both
sides-
I'm
relatively
neutral
on
this
point
I,
although
I
actually
do
feel
fairly
strongly
about
the
text.
In
the
current
document
that
says,
we
should
register
port
465
as
a
port
that
has
dual
use
in
the
wild
and
I
know.
The
registry
folks
won't
like
that.
B
I'm
not
entirely
remembering
what
the
be
speed
the
generic
PCP
says,
but
I
think
it
has
like
a
few
because
we're
talking
about
TLS
in
the
board.
It
has
some
recommendations
but
also
says:
there's
these
other
side,
/
suites
that
are
still
only
two
or
if
you're,
in
this
situation.
You
might
want
to
do
that
catering
for,
like
you,
know
the
job
environment
which
have
the
short
diffie-hellman
values
and
so
on
right,
I.
Think
in
this
case
we
don't,
we
don't
have
to
be
so
constrained.
D
D
A
B
B
B
E
So
I
keep
working
I
feel
like
the
thing
with
the
cipher.
Suites
is.
If
you
tie
this
to
some
external
document
that
can
change,
then
you
might
actually
break
in
or
ability
when
that
set
of
cipher
Suites
changes
and
you'll
have
skew
between
one
implementation
and
other
about
which
things
they
implement.
E
So
I
actually
think
that
the
time
unit
you're
going
to
have
a
binding
of
those
things
you
should
bind
to
a
specific
document
not
to
you
know,
like
a
bcp
number
or
something
like
that,
and
even
though
we
realize
these
recommendations
will
change
over
time
that
has
to
be
propagated
back
to
the
application
protocol.
Specs
yeah.
B
B
D
Okay,
moving
on
to
the
fourth
bullet,
there
has
been
some
controversy
on
the
list
about
document
or
court
organization
and
clearly,
and
so
I
mean
I.
By
the
way
the
documents
currently
structured
is
I
came
up
with
a
set
of
yo
yo.
There
are
a
set
of
ideas
that
all
move
towards
the
same
goal:
I
wrote
them
roughly
in
the
order,
I
thought
of
thug
and
then
I
tried
to
and
then
I
moved
from
around
to
try
to
eliminate
forward
references.
So
that's
the
current
document
organization,
I.
D
My
request
on
this
topic
is
that
the
as
that
the
term
bcp
not
be
used
as
part
of
this
discussion,
I'm
okaying
various
organizations,
but
I
don't,
but
I
don't
think
bcp
is
a
constructive
categorization
mechanism,
partly
because
you
can
talk
to
two
different
IETF
people
and
get
two
different
thoughts
on
what
should
go
in
and
bcp,
and
what
shouldn't
so
I'd
like
to
have
this
discussion
at
the
level
of?
Can
we
put
this
section
before
a
disc
session
and
one
of
the
things
I
wanted
to
point
out.
D
Russ
actually
made
some
suggestions
on
reordering
sections
that
I
thought
made
sense
to
me
and
I'll
just
do
them
so
anyway,
I
wanted
to
invite
suggestions
to
improve
the
organization
it
did.
Anyone
want
to
have
additional
comments
on
that
topic,
or
shall
we
just
continue
discussing
that
on
the
list.
B
About
to
go
bad
I
personally,
find
it
interesting.
If
somebody
would
comment
on
them
describe
about
the
draft
saying
this
is
how
it
is
done
in
election
today
may
not
represent
the
best
compact
package.
All
right
and
that's
a
separate
thing.
That's
a
completely
enslaved!
Somebody
has
information
out
there
about
the
employment
experience
high
hopes,
high
security,
interesting
to
get
that
some
of
that
down
on
paper.
That's
not
what
you're
trying
to
do
right.
D
Yeah,
so
good,
so
I
am
this
documents
focused
on
the
MUA
to
server
Hawks.
You
know
pop
IMAP
and
submission
only,
but
the
MTA
relay
hot
too
hot
model
is
different
and
is
very
different
and
broken,
and
there's
some
sort
of
de
facto
agreements
happening
out
there
right
now
in
the
wild.
But
you
know
I
can
tell
you
my
involvement
with
service
providers
as
a
mail.
Server
engineer
is
that
yo
service
providers
are
having
to
wire
up
special
one-to-one
agreements
for
certificate
validation
right
now,
because
the
standard
there
is
nothing
written
down.
D
That's
clear
enough
about
how
to
validate
certs,
and
if
you
do
write
something
you
have
to
write.
Well,
you
can
validate
this
way,
which
is
secure,
but
a
lot
of
sites.
Don't
do
that,
so
you
have
to
validate
it.
This
way,
which
is
not
secured
properly,
and
so
the
current
practice
is.
There
is
no
Oh
active
attacker
protection
for
MTA
MTA
Hawks
right
now,
when
hit
bottom
line,
except
ones
that
have
been
specifically
configured.
D
D
Ok,
so
that
was
I
think
the
end
of
my
slides,
although
they
just
went
black,
oh
yeah,
I'm
working
group,
specific
document
text,
suggestions,
I'm
open
to
anything.
You
know
that
now
is
the
time
to
get
them
done,
because
the
technical
content
is
yo
other
than
the
issues
we
just
discussed.
Pretty.
You
know
pretty
close
to
done
so
any
other
topics
on
this
document
actually.
B
When
asked,
could
we
have
yours
run
how
about
concussion
or
any
version
of
the
draft?
Okay?
Let's
do
that
so
I'm
I
would
very
much
like
to
see
a
couple
and
somebody
who
volunteered
to
reminisce
just
to
even
if
it's
just
to
say
then
it's
okay
or
it's
looking
to
event
that
I
can
somebody
went
in
to
get
a
cup
of
mojitos
to
commit
to
doing.
A
B
A
Volunteer
last
time
they
do
it.
So
I
actually
did
read
it
I
sense
email.
Yet
Chris
can
you
explain?
Maybe
you
know
I'm
completely,
forgetting
someone
explain
it
well
but
say
a
client
latches
on
1.1
and
the
TLS
1.2.
So
the
server
says:
hey
I'd
you
can
put
one
and
only
in
it,
Clyde
latches
the
surrogates
upgrading,
because
1.2,
when
does
the
client?
When
is
it
able
to
upgrade
to
1.2.
D
D
A
A
B
A
A
B
A
C
This
is
people
make
the
same
coin,
which
organs
I
don't
remember,
but
does
the
client
have
the
option
to
say
I,
don't
accept
one
of
laches,
cuz
I,
don't
know
it
was
screwed
up
right.
I
think
the
idea
is,
is
they're
going
to
come
a
point
where
we
write
a
bcp
that
says
deal
us
you're
always
hose.
You
should
not
use
it
anymore.
It's
as
bad
as
using
bad
bogan,
crypto
and
Clarence
should
say:
I,
don't
watch
or
10.
Even
if
you
tell
me
to
is
that
it
is
a
possibility
in
what
you're
ready.
D
D
C
E
Or
the
other
thing
is
that
you
know
TLS
Forks
in
such
a
way
that
the
version
numbers
are
no
longer
linear,
but
there's
some
other
facility
besides
TLS
that
you
might
want
to
start
using
and
then
everything
is
latched.
Els
will
sort
of
need
to
walk
back
up
and
do
something
else
and
we're
not
necessarily
planning
for
that.
B
D
E
Yeah
this
area,
envisioning,
is
the
server
supports,
1.3
and
then
somewhere
down
the
line.
Some
other
technology
becomes
favored
and
I
mean
with
the
clients
of
all
rushed
13
and
we'd
have
to
define
the
latches
in
such
a
way
that
it's,
like
you
know,
X
Y,
Z,
1,
point
0
and
actually
greater
than
or
equal
to
TLS
1.3.
C
D
We
have
a
commitment
for
review
from
david.
Did
we
have
a
commitment
for
review
social
alone?
Oh
absolutely
thanks.
I
really
appreciate
the
reviews
and
I'm
going
to
I'm
going
to
start
trying
to
chase
down
quiet
authors,
mail,
client,
authors
and
get
them
to
review
that
we
weren't.
So
if
anybody
has
contacts
at
their
company
with
mail,
client
authors,
I
would
appreciate
comments
from
them
because
there's
always
the
problem
in
the
email
space
of
most
of
the
specs
or
written
by
server
event,
yo
server
engineers
and
the
plan.
D
B
Us
at
the
end
of
a
agenda
we
have
connect,
as
you
can
all
see
yourself
approaching.
The
you
can
sorta
see
me
under
the
light
at
the
end
of
the
tunnel,
for
this
working
group
is
that
chocolate?
There
is
one
item
that
we
haven't
progressed
and
that's
some
sort
of
general
advice
of
opportunistic,
sir
cage
for
TLS.
It's
cooler
out
of
conversation
with
Stephen
I,
don't
know
if
you
can
speak
to
this
topic
Stephen,
but
is
that
cool
to
any
of
us
that
we
even
know
what
the
problem
is
and
have
to
formulate
anything?
C
Normally
I
would
just
transfer
stuff
over
to
Barry,
since
I
don't
have
a
replacement,
but
where
the
process
of
doing
a
little
bit
of
iesg
reorganization,
one
of
the
things
we
did
was
make
it
possible
to
have
a
directors
that
are
not
in
the
area
be
responsible
for
the
group.
I
think
it's
still
useful
to
have.
This
is
an
absurd,
a
regular,
because
we
want
to
encourage
applications.
People
to
be
looking
at
this
that
it's
for
them,
it
sounds
like
Stephen
is
running
to
be.
C
The
irresponsible
I
am
irresponsible
area
director
for
the
working
group
going
forward
so
lightly
at
the
next
week,
when
a
little
shuffle,
those
on
Stephen
will
end
up
with
his
name
on
the
data
tracker
for
the
responsible
AED,
and
there
is
a
word
document
and
publication
requested
which
magically
become
siemens
problem
instead
of
mon-sol
reconfirmation
formation
by
wednesday
of
ever
will
see
if
I'm
very
motivated
in
these
next
day
or
barrier.
One
of
us
will
do
the
ad
evaluation
point.
It
will
get
it
unstuck.
You
know
goal
in
the
process.