►
From YouTube: IETF99-NFSV4-20170720-0930
Description
NFSV4 meeting session at IETF99
2017/07/20 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
A
C
B
B
But
welcome
if
you
join
later
on,
I
am
in
the
jabber
room
and,
let's
start
the
meeting
I've
already
checked
for
the
participants
in
the
room.
It's
a
it's
an
unusual
showing
for
nfsv4
for
anybody
out
there
and
the
listening
to
this
and
and
I
guess
we'll
be
recording
it's
a
it's
a
pretty
robust,
showing
here
in
Prague,
because
this
is
a
one
of
the
favorite
places
for
the
NFS
version
for
group
to
meet.
B
You
got
the
blue
sheets
signed
I've,
seen
that
we're
gonna
bash
the
agenda
quickly
and
I
have
Tom
Haines
up
front
here,
helping
a
lot
and
he'll
be
doing
the
projections
so
any
additions
to
the
agenda
as
see
nice.
So
this
is
being
this.
What
it's
played
Spencer
tell
me:
I,
don't
have
to
do
anything
to
display
this
stuff
on
its
just
magically
all
happening
right.
D
B
D
B
It's
kind
of
frightening,
actually
I'm
gonna
find
one
okay,
so
gender
bashing
do
we
have
any
additions
beyond
changes?
We
just
made
a
Novick
Dave
Novak
has
put
together
those
slides
following
his
email
push
on
the
reach.
Our
discussion,
Tom
Haines
has
added
a
where
to
next
set
of
slides
from
Tron
and
him
at
the
end.
Is
there
any
other
additions
changes.
B
B
If
you
are
aware
of
anything,
that
is
something
that
we
should
know
about
in
terms
of
encumbrances
and
such
regarding
IP
for
any
of
the
items
under
the
discussion
for
the
working
group
or
within
the
documents,
it's
upon
you
to
disclose
them
to
the
IETF,
and
then
we
figure
out
where
to
go
from
there.
That's
the
gist
of
the
note
well,
but
if
you'd
like
to
read
it
again,
please
do
at
your
leisure.
B
F
Properly,
maybe
ok
sure
anyway,
so
this
this
document
has
been
in
ad
is
watching
for
a
long
time
and
now
you'll
you'll
have
something
to
watch,
I,
hope,
alright,
so
I'm
I'm
gonna
go
over.
What's
what's
been
happening
up
to
a
version
12
to
12
recent
changes,
the
work,
that's
in
progress
now
as
the
future
documents
that
expect
to
come
out
of
it
and
the
next
step,
and
then
finally,
there
will
be
an
end
of
this
document
migrations.
F
We
know
it
was
a
13
or
14
or
15,
but
then
it
will
be
over
okay,
let's
go
up
okay.
This
start
document
started
in
April,
2008
2012,
and
it
was
co-author
with
with
Chuck,
with
your
shabam
and
Bill
Baker.
Initially,
the
focus
was
the
manifesto
and
eventually
came
out
of
it.
It
was
a
standards
track
document
which
was
published
as
RFC
791.
F
So
after
we
published
that
RFC
doc
who
needs
to
shift
so
first
of
all
the
before
ode
treatment
I,
the
number
of
revisions
I
slowly
moved
from
proposing
things
to
fact
to
recognize
fact
that
actually
that
happens
finally
described
them
and
also
there
was
a
need
switch
from
before
dollar
division,
for
which
I
so
put
off
her
looking
for
too
long,
but
eventually
we
had
to
move
to
the
for
that
one
all
right
head.
He
gets
recently
we've
gotten
more
serious
about
be
poured
on
one
state
migration
for
a
while
I've
been
assuming.
F
That
would
be
simple.
We
didn't
have
the
problem
with
uniform
and
non-uniform
client,
ID
client,
these
strings.
So
I
said:
oh,
we
don't
have
that
so
it'll
be
easy.
You
remember
that
oh
yeah
easy,
then
Chuck
guys
try
some
things
and
we
found
out
it
wasn't
so
easy
so
had
to
confront
some
trucking
struggling
discovery
issues.
Ok,
the
oracles
been
shown
there
were
more
problems
than
I
had
thought
and
also
about
the
same
times.
F
We
need
to
confront
different
sores
hand,
trunking
discovery
issues,
but
before
that
I
would
before
that,
wasn't
it
lately,
it
turned
out
those
two
things
need
to
move
to
merge,
also
I
needed
to
deal
with
the
interaction
of
migration
and
trunking,
which
are
related
and
as
a
result
of
that,
the
best
thirteen.
The
document
has
a
new
title,
which
is
nfsv4
migration
and
trump
trucking
implementation
and
specification
issues.
F
And
if
you
want
to
read
it,
you
can
read
it
so,
and
one
of
the
big
changes
is
there's
a
new
focus
on
before
that
one
state
migration.
So
this
is
part
of
the
results
of
issues
discovery
by
the
oracle
experiments,
one,
the
confirmation
status,
transferred
client,
IDs
and
second
of
all,
it
was
a
seemingly
minor
change.
F
Now
it's
an
indication
you
can
deal
with
that,
a
that's
some
implication
of
that
there
dealt
with
into
the
document.
Also,
I
started
to
look
more
cool,
well
close
meant
closely
at
migration
in
five
six
six
one
and
I
found
lots
of
stuff.
I
said
whoever
wrote
this,
it
turns
out.
It
was
me,
but
but
there
were
problems
and
we
need
to
deal
with
it
alright,
so
many
of
the
issues
have
been
ignored
session
migration,
which
you
know
truck
shuts
it.
But
what
about
citizen?
My
gracious,
oh
yeah!
F
So
the
Orca
experiment,
Oracle
experience,
show
a
couple
things
one
which
I've
mentioned
before
is
but
the
status
of
transferred
client
ID
and
turns
out
that
there's
some
things
in
exchange
ID,
which
it
uses
uses
the
word
must
incorrectly,
but
it
seems
like
they
have
to
change.
Otherwise,
you
can't
make
this
thing
work
and
also
I
had
to
address
the
statin
of
the
C
4
status.
Flags
and
the
implications
of
these
move
not
be
being
error.
F
So
this
may
be
some
some
treatment
of
that
issue
and
I
had
to
address
that's
currently
and
that's
in
they're
changing
the
relationship
of
PN,
FS
and
migration.
So
you
have
I
figure.
You
have
to
support
migration
of
an
MDS
well,
leaving
migration
of
the
whole
file
system,
including
the
MDS,
the
data
servers
or
migration
between
Fosse's
them
you've
gone
from
a
file
system
that
supports
p
NFS
to
one
that
doesn't
advise
person.
F
You
have
to
have
some
text
about
that
and
either
this
document
or
the
ones
that
come
out
come
out
connect
with
all
right
Scott.
Now
the
big
thing
big
thing
is
changing
handling
of
trunking
in
Florida
Doe.
There
was
no
initially
no
means
of
trunking
detection
scarpered
and
read
the
text
of
thirty
five.
Thirty
and
since
conservative
senator
75
30
base
achill
e
trucking
was
not
a
feature
but
a
problem,
something
obnoxious.
Something
is
odious
and
basically
there's
every
effort
and
35:30
to
get
out
of
it
and
7931.
F
There
isn't
means
in
trucking
detection,
it's
basically
a
feature,
but
it's
an
optional
feature
before
I
won
it's
essentially.
Well,
it's
not
a
word
managers,
but
there
is
something
that
is
returned.
Everyone
can
rely
on
it
and
it's
really
a
true
feature.
So
both
those
both
those
versions
have
to
deal
with
the
issue
of
well.
Yes,
you
can
discover
trunky
some
and
also
whenever
you
discover
a
trunk
in
relationships,
they
can
change
and
you
have
to
make
provision
in
the
spec
for
them
changing.
F
All
right,
what
I'm
working
on
now
I'm
working
in
looks
good.
This
is
this
is
an
intermediate
slide
between
that
was
when
I
actually
brought
this
I
was
working
on
it
now
it's
sort
of
in
the
future
document,
but
anyway,
basically,
the
big
problem
in
migration
in
56
is
the
one
I
advise
I've
read
it
was
it
says:
gee
you
can
have
an
address,
a
and
B
at
to
get
to
a
particular
possitive
and
treats
them
exactly
says.
Oh
yeah,
these
these
two
replicas
and
address
a
and
address
B.
F
As
a
result,
it
obscures
the
fact
that
trunking
is
gone
and
says.
Oh,
this
is
too
red
replicas
on
a
and
B
and
magically
the
coordinated
and
didn't
treat
it
address
trunk
trunking,
but
implicitly,
in
a
way
that
was
very
hard
to
do
and
when
I
try
to
pull
those
apart.
Ted
change
a
lot
of
things
in
the
document
and
that's
what
we've
seen
also
result
of
that
it
was.
There
was
confusion
with
other
cases
of
when
which
two
different
replicas
truly
different
relatives
we
dealt
were
dealt
with
simultaneously.
F
So
we
need
to
distinguish
trunking
from
using
two
replicas
simultaneously
and
distinguish
migration
from
switching
Network
addresses
without
migration
and
as
a
result,
this
was
my
opinion.
One
of
my
big
confusions,
biro
556,
was
treatment
of
service
coat
I,
somehow
soom,
that
if
you,
if
you
share
the
same
scope,
could
somehow
have
some
degree
of
ID
sharing
and
turns
out
that
happened.
Basically,
people
who
have
to
have
the
same
service
coat
they.
Basically,
while
it's
used
as
a
qualification
for
server
I'm,
a
server
owner
and
basically
I,
rewrote
that
to
reflect
what
what
happened.
F
A
A
F
Right
and
then,
of
course,
the
big
gap
was
well
basically,
while
seventy-five
Hillary
talk
about
transparent
state
migration
and
made
some
mistakes
about
about
it.
Fifty-Six
to
see
when
talk
about
Prince
apparent
state
migration,
really
at
all,
essentially
and
so
I
had
to
correct
that.
Let's
go
on
now,
so
there
are
two
future
documents
which
are
being
prepared
of
some
pre-draft
I'll
submit
a
mine
that,
sometime
after
iodine
nine,
probably
not
been
this
month,
but
soon
thereafter,
one
is
draft
Adamson
atom
NFS
before
I
haven't
mv0
trunking
update
that
will
address
the
four
dollar
issues.
F
Basically,
it
will
provide
trunking
in
a
way
that
wasn't
there.
Basically,
what
happened
is
with
7931.
We
so
gave
them.
We
told
you
how
to
do
trunking,
but
it
was.
There
was
trunking
detection
without
trucking
discovery
and
basically
that
fills
that
gap
and
and
integrates
integrates
trucking
with
migration
in
a
way
that
was
that
also
be
doesn't
for
that
one,
but
they're
different
because
imported.
Oh
it's
an
optional
feature,
and
then
I'm
prefer
working
right
now
on
draft.
You
know
that
inefficient
for
mv-1,
multi-service,
namespace,
update
and
I'll
address
it
before
what
issues.
F
Now,
as
I
said,
these
IDs
will,
unless
given
a
promising
date,
but
probably
my
pick
mine
will
next
month,
I'm
sue
Mandy's
will
be
about
that.
The
same
thing
and
those
could
be
basis
first
end
track
documents
in
the
working
group.
Oh
well,
it
Chuck
mentioned
requests
to
working
group
I'll,
probably
at
this
meeting.
You
know
since
me
all
about
the
fact
that
you
know
that's
something
that
the
world
should
consider.
F
All
right
now,
this
is
actually
a
slide
to
provide
this
by
it
by
Andy
Andy.
All
right
so
he's
he's
the
lead
author,
but
it's
also
co-author
with
Chuck
and
me
and
paralyzed
parallels
the
the
treatment
a
forever
for
Roberta
zero
of
the
multi
server
namespace
update
for
before
that
one.
It
dad's
trunking
as
an
emphasis
occasion,
attribute
feature
as
as
I
didn't
do
it
my
date
document
migration
issues
were
already
handled
in
$0.75
in
RFC,
7931
and
I
think
satisfactory.
F
I
F
F
F
F
F
You
can't
do
trunking
detection,
but
you
can
use
the
server
host
names
that
DNS
provides
in
the
case
where
DNS
provides
multiple
IP
addresses
as
a
new
section
under
action
of
trunking
migration
and
replication,
but
that
doesn't
modify
it
adds
to.
It
doesn't
mind
that,
if
modified
to,
what's
in
so
931
and
there's
some
new
security
considerations,
check
text
each
other,
okay,
now
I'm
working
on
this
document
right
now,
the
update
forum
love
deserve
a
namespace,
and
that
also
is
co-authored
with
that's
caught
that
was
Chuck
and
with
Andy.
F
So
one
is
the
lack
of
a
state
migration
section
in
56
61,
my
fault,
but
it's
be
corrected,
left
field
with
the
possibility
of
session
migration
and
we'll
deal
with
the
differences
in
the
recovery
model
model
due
to
the
C
4
status
fits
and
PFS
end
session
migration,
as
I
mentioned
before,
and
the
mishandling
of
trunking
in
RFC
cc1,
and
this
winds
up
for
fine
providing
for
before
dot
one
trunking
discovery
as
opposed
to
truck
me.
This
cut
the
skype
detection.
F
So
this
so
I
think
this
is
actually
in
response
to
a
question
to
Andy
that
Chuck
said
earlier.
Ok
basically
ended
earlier
document
on
truckin.
It's
basically
replaced
for
before
dot
one
by
this
document
and
for
for
a
4.0,
it's
replaced
by
the
document,
so
Andy's,
probably
gonna.
Just
let
that
document
inspire
and
be
replaced
by
that.
I
Document
is
client,
multi
print,
it's
named
client,
multi
path,
and
it's
currently
a
personal
draft.
This
Chuck,
Weaver
or
Cogan
had
a
question
or
comment
about
the
session.
Migration
I
think
that's
important
to
document,
but
I'm
not
aware
of
any
plans
of
an
implementation
by
any
vendor,
so
that
that's
kind
of
a
concern
that
we
won't
be
able
to
test
the
completion
of
the
session
migration
comments
that
you're
gonna
put
in
this
document.
Well,.
I
C
I
K
M
C
So
the
flux
law
document
has
been
on
hiatus
for
two
years.
We
passed
it
through
the
working
group
last
call,
and
yet
we
had
our
major
review
that
came
in
so
we
unpassed
it
and
I've
finally
taken
care
of
all
of
the
review
comments
and
the
one
that's
kind
of
lingering
out
for
me
is
the
FDS
state
ID
conundrum,
which
is
inside
the
layout
type.
C
We
present
a
state
ID
for
v4,
but
all
of
the
existing
implementations
are
only
d3
and
if
s
d3
so
the
v4
state
ID,
it
should
have
been
an
array
of
state
IDs
to
match
the
array
of
file
handles
and
we
can.
We
can
pave
over
it
and
say:
oh
no.
We
really
meant
for
an
anonymous
state
ID
in
the
loosely
coupled
and
a
globally
state
ID
in
the
tightly
coupled.
C
C
Do
we
want
it
so
that
there
is
a
concern
in
do
we
want
to
say
that
this
you
we
can
address
this
in
a
future
release
of
the
update
of
the
stack,
because
it
can't
it
the
reason
it
can't
be
addressed
in
the
current
spec
is
we
have
two
implementations
that
are
pretty
much
shipping
and
we
would
break
if
we
changed
the
this
field.
We
would
break
them.
So
anyone
with
any
thoughts
Dave
said
we
don't
call
it
a
bug.
So,
okay,.
C
C
The
other
thing
that
I
took
care
of
outside
of
days
review
was
the
loosely
coupled
security.
We
had
done
this
saying:
it'll
be
secure
and
I
knew
that
wants
to
get
out
of
the
working
group.
It
was
going
to
be
shot
down,
so
we
had
talked
about
several
different
models
in
one
of
the
prior
meetings
and
I
went
with
the
client
in
the
MDF
connect
to
the
main
authentication
server
for
the
metadata
and
the
the
problem
then
becomes
in
that.
C
With
this
model,
we
pass
a
synthetic
UID
GID
to
the
client
and
it's
supposed
to
prints.
It
present
that
to
the
storage
devices
and
how
do
we
in
essence
generate
these
tickets
on
the
fly?
Well,
we
make
the
MDS
also
be
a
KDC
for
the
data
path
and
allow
it
to
give
the
client
a
ticket
for
the
session.
Scott
we've
still
half
the
fence
by
modifying
the
UID
and
GID.
C
C
If
we
have
recallable
object
types
and
if
you
read
56
61
carefully,
you'll
find
one
place
where
it
says:
it's
not
another.
Edge'
stre
and
you'll
find
another
place
where
it
says
it
is
a
registry
one
place
won't,
doesn't
allow
for
updates.
The
second
place
does
so
I've
decided
to
go
with
the
second
place
that
does
allow
it
and
I've
added
a
request
for
the
layout
for
the
Flex,
but
I
also
noticed
in
the
56
61,
where
didn't
call
for
an
update.
A
C
And
then
the
the
the
other
ass
that
came
out
was
from
Ric
Mackel
man
was,
which
was
right,
one
mirror.
Basically,
we
we
have
the
F
F
flags
for
which
are
extensible,
so
I
could
make
this
change.
We
added
a
new
flag,
and
so
the
client
will
write
to
one
mirror
and
that
mirror
will
update
all
the
remaining
mirrors.
C
It
needs
to,
however,
report
any
errors
to
the
client,
because
the
only
way
that
the
MDS
can
is
aware
of
an
error
on
the
storage
device
is
from
the
client
telling
it,
and
then
we
also
define
the
commit
semantics
for
this
functionality
and
another
honestly
I.
Don't
know
if
he's
gonna
implement
this
when
he
asked
me
to
do
it,
I
was
busy,
I
didn't
do
it
and
then,
when
I
delivered
it
to
him,
he
said.
Oh
I,
don't
need
it
anymore,
but
you
know
go
back
to
wanting
it.
C
So
I
don't
have
a
slide
on
lessons
learned,
but
lessons
learned
would
be
I
wish.
We
hadn't
talked
at
all
about
v4
as
a
storage
device
protocol
I'd,
rather
talk
about
the
things
we're
trying
to
implement
right
and
I'd,
rather
focus
on
having
code
that
works
and
then
having
you
know,
a
standard
that
we
can
push
at
the
same
time
just
becoming
my
pet
peeve.
So
going
back
to
this
slide,
it's
been
in
the
last
call
for
a
long
time
we're
at
version
9
officially
for
this
meeting.
Actually
it's
at
11.
C
B
Right
and
and
Spencer
just
Spencer
basically
said
to
take
the
document
you
have
now
that
addresses
all
the
yes
issues
that
came
up
in
the
interim
and
we'll
push
that
for
a
working
group.
Last
call
when
you
are
twiced
tomorrow,
if
there's
no
more
comments
from
people,
if
you
haven't
signed
the
blue
sheet,
Simon
Lucy
is
how
we
keep
our
room.
C
Then
I
don't
have
it
here,
because
I
didn't
think
I
was
gonna.
Have
her
ready,
I've
also
got
the
layout
types
thought
someone
threw
the
rivet.
It
went
through
the
same
conundrum,
and
it's
also
as
of
like
6:30
this
morning,
because
I
was
jet-lagged.
It's
been
updated
for
the
review
comments
and
I'm
going
to
also
push
it
for
working
good.
Last
call.
B
I
I
So
we
know
what
DMA
is
that's
a
device
that
is
able
to
access
post
memory.
Remote
DMA
is
when
the
device
transfers
data
from
host
memory
to
a
remote
hosts
on
the
network,
the
point
being
that
the
data
movement
is
offloaded
and
the
CPU
is
not
involved
with
the
with
the
movement
of
individual
bytes.
So
NFS
I've
already
may
use
this
mechanism
to
move
data
fields
of
I/o
operations
that
is
read
and
write
in
the
next
slide.
I
Times
greater
throughput
over
and
if
it's
over
TCP
for
large
payloads,
in
fact,
I
was
able
to
get
NFS
read2go
at
line
rate
as
soon
as
we
got
big
payloads,
so
it
was
moving
very
close
to
52
to
56
gigabits.
A
second
I
can
double
the
AIIMS
rate,
a
kilobyte
by
ops,
over
TCP
NFS
on
TCP
and
another
benefit
that
that
we
really
like
is
in
VM
guests.
I
We
can
see
very
good
performance,
usually
with
NFS
over
TCP,
there's
quite
a
bit
of
overhead
for
doing
network
operations,
but
with
a
virtual,
our
DMA
device,
virtual
HCA
and
a
guest
we
get
close
to
bare
metal
performance,
so
I
think
that's
important
for
virtualization
environments.
Next,
the
downside
is
a
adoption
story
and
I
I
list.
Some
ball
points
here.
You
know
this
is
full
disclosure.
You
know
he
laughed,
but
it's
it's
full
disclosure
I'm
listening.
Some
bullet
points
on
this
slide
that
that
itemize.
I
Some
of
the
reasons
why
an
offensive
already
may
hasn't
been
well
adopted
so
far.
One
of
the
important
reasons,
most
important
reasons
is
that
you
gotta
have
an
up
to
recently
had
happen.
An
IB
card
in
your
machine
to
do
it
these
days,
we're
getting
convert.
Cheater
net
implementations
have
already
made,
and
an
especially
a
software
version
of
this,
where
you
don't
have
to
have
specialized
hardware
at
all,
you
can
do
it
with
a
standard,
Ethernet
NIC.
I
I
I
Well
nowadays,
you
know
back
back
when
we're
talking
about
ten
gigabit,
InfiniBand
Pro,
that's
probably
true,
but
now
that
we're
talking
like
56,
100,
gigabit,
InfiniBand
and
ethernet,
it's
fear,
and
these
fast
storage
devices,
it's
very
clear
that
there
is
a
benefit
to
to
offloading
data
movement,
and
then
I
should
mention
that
the
code
that
is
in
front
of
people
right
now
in
Linux
distributions
Inlet
for
Linux,
is
fallow.
It
wasn't
developed
for
quite
a
span
of
time
between
about
2010
and
2014
and
that's
the
code.
I
That's
in
the
most
widely
deployed,
Enterprise,
Linux
distribution,
and
so
people
can't
use
it
because
that
the
the
server
it
doesn't
work
manifests
overall,
ready-made
capability
does
not
work
in
rl6
and
the
client
has
some
operational
problems,
it
Hanks
and
crashes.
So
the
one
in
rel
seven
is
actually
pretty
good,
but
the
one
in
rel
six,
which
is
a
common
one,
is
not
so
that's
why
people
have
not
widely
adopted
it
next
slide.
Please
and
I.
Just
thought.
I
I
All
right,
sorry
8167
is
a
new
is
a
new
thing
right
as
number
one
anyway.
8167
allows
us
to
do
nfsv4
point
one
and
already
made
transports,
because
we
didn't
have
the
capability
of
doing
bi-directional.
That
is
callbacks
on
the
same
connection
with
our
DMA,
and
now
we
do
with
this.
Rfc
explains
exactly
how
to
do
it
and
we
have
implementations
of
it.
The
next
thing
that
I'm
working
on
right
now
is
50
667
bits
that
will
update
the
NFS
upper
layer
binding,
which
will
that
will
make
the
else
the
cycle
complete
next
slide.
I
So
this
is
the
entire
list
of
personal
IDs
that
are
outstanding,
I
guess
as
two
weeks
ago
for
this
working
group
and
they're
all
in
some
way
relates
the
argument.
Interesting
night
I
thought
I
put
this
up
here,
just
sort
of
summarize
the
the
what
the
work
working
group
is
up
to
it's
pretty
much
all
focused
on
improving
an
offensive
already
May
next
slide
and
then
just
to
mention
the
implementation
work
that's
been
going
on
for
the
last
18
months
or
so
in
Linux.
I
We
have
nfsv4
point
one
on
our
team
a
now
thanks
to
the
bi-directional
RFC
that
I
just
mentioned.
We
also
brought
our
peds
support
for
RPC
sec2
NFS.
Over
already
may
solaris
had
this
for
years
and
now
linux
does
we've
been
doing
interoperability
testing
between
these
two
implementations
with
a
high
degree
of
success,
they're
a
couple
of
corner
cases
that
are
still
not
working.
M
F
J
M
I
They
have
they
have
patches
up
to
upstream
colonel
for
that
eight
or
nine
in
well
7.4,
which
means
they
should
have
nfsv4
point.
One
support
and
we've
been
discussing
support
for
Kerberos
kerberized
NFS
I've
already
made
in
their
products,
so
they
are
interested
in
taking
it,
I'm,
not
sure
if
they
have
yet
so
either
in
the
current
7.4
or
in
the
next
7.5
I
would
expect
to
see
it.
I
I
should
also
mention
that
I've
been
doing
thanks
to
some
urging
by
Tom
Haines
I've
been
working
on
fixing
the
Wireshark
dissector
for
our
PC
over
our
team,
a
which
was
completely
not
working
before
so
it's
at
least
functional
now
and
it
passes
our
team
a
frames
to
the
RPC
dissector
appropriately.
The
one
thing
in
that
it
doesn't
do
right
now
is
it
does
not
handle
chunks
at
all.
I
These
things
are
two
or
three
orders
of
magnitude
and
I'm,
not
exaggerating
faster
than
what
we,
what
we've
had
and
the
even
even
things
like
SATA
SSD.
So
a
primary
consideration
is
that
they're
so
fast
that
they're
outpacing
the
ability
for
the
NFS
and
RPC
stack
on
the
client
to
keep
up
with
them.
In
other
words,
the
latency
of
going
through.
I
I
We
have
we've
identified
some
issues
with
the
protocol
in
terms
of
NFS
server
operation.
That
is
that
the
two
bullets
here,
the
first
one,
is
that,
since
the
server
drives
already
made
reads
and
writes,
write
comes
from
an
RPC
reply,
but
read
is
done
when
a
large
call
is
made
and
the
read
the
call
is
made
from
the
client.
The
server
has
to
read
the
data
to
this
server
and
then
it
can
operate
on
it.
I
So
there's
an
extra
round
trip
in
there
that
we,
it's
not
so
bad
for
large
payloads,
but
it
is-
is
somewhat
onerous
for
moderate
payloads,
like
eight
kilobytes
or
16
kilobytes.
So
we'd
like
to
do
something
about
that,
and
the
other
problem
is
that
the
RPC
of
already-made
was
architected
so
that
during
the
XDR
parsing
of
an
RPC
call,
our
DMA
reads
could
be
done
to
pull
the
data
over.
I
The
problem
is,
if
you
want
to
identify
what
memory
you
want
to
read
into
the
best
thing
to
do
is
wait
until
you've,
actually
parsed
the
NFS
file
handle,
and
that's
not
done
in
the
XDR
layer.
It's
done
up
in
the
the
top
layer,
the
NFS
server
figuring
out
what
file
system
that
goes
in
what
I
know
that
goes
with.
So
at
that
point
you
can
actually
pick
the
the
the
pages
that
you
do,
the
our
team,
a
reading
to
to
eliminate
another
data
copy.
I
So
I
think
we
don't
have
any
implementations
that
do
this.
It
might
be
possible
with
Linux
and
I'm.
Looking
at
that,
right
now
and
I'm
not
sure
whether
that's
going
to
be
a
protocol
issue
or
an
implementation
issue,
we'll
see
next
slide,
there
are
some
significant
client
operational
issues
that
are
the
result
of
the
protocol.
I
One
is
that
we've
got
a
problem,
handling
POSIX
signals
when
a
signal
happens
like,
for
example,
user
does
a
control
see
the
RPC
that
is
going
at
the
time
has
to
be
terminated,
and
that
is
we
require
that
this,
that
the
client
invalidates
the
right
chunks
that
are
associated
with
that
RPC,
which
makes
them
inaccessible
to
the
server.
But
the
server
doesn't
know
the
RPC
was
cancelled,
so
it
will
eventually
try
to
write
into
those
chunks
and
when
it
does
that
we'll
get
a
remote
access
error
and
probably
the
connection
will
be
lost.
I
So
that's
kind
of
catastrophic.
We
don't
want
control-c
to
cause
that
kind
of
interruption
in
service.
Certainly
it's
quick
to
recover
from
that,
but
there
are
other
consequences
to
lose
any
connection
that
we
it's
just
not
desirable.
So
we
like
to
have
some
way
of
terminating
our
pcs
in
a
way
that
the
server
isn't
going
to
cause
the
connection
drop
next
time
it
tries
to
reply,
then
the
other
boat
here
is.
We
have
a
number
of
par
cases
with
how
the
credit
management
mechanism
works.
I
It
basically
works
fine,
but
there
there
are
certain
cases
that
will
cause
a
credit
overrun.
The
one
that
we've
been
discussing
in
the
working
group
recently
was
detecting
server
crashes
or
network
partitions
when
the
credit
count
is
full
and
if
the
client
ascends
another
operation,
it
has
to
send
a
send
work
request.
It
can't
do
it
right
because
right
is
not
acknowledged
and
the
send
will
time
out
immediately
if
it
can't
get
through
the
server.
So
the
client
wants
to
do
a
send.
I
The
problem
is
sends
our
flow
control,
and
so,
if
it
over
flows,
the
credit
count
it's
going
to
cause
a
connection
loss
and
that's
another
case
where
we
just
don't
want
to
force
a
connection
loss.
If
we
don't
have
to
right
now
our
implementations,
when
we
re
transmit
our
pcs
at
the
upper
layer,
we
actually
drop
the
connection,
because
that
we
can't
account
for
credits
on
both
ends.
I
When
we
read
transmit
an
RPC
and
then
there's
the
case
where
we
want
to
start
sending
unidirectional
messages,
that
is
our
credit
accounting
works,
it's
sort
of
layered
on
top
of
RPC
call
and
reply,
so
it
requires
an
antiphonal
communication
between
client
and
server.
The
client
does
a
request
how
many
credits
do
I?
Have
this
server
replies
with
a
grant?
I
And
so
it's
a
two-way
thing,
and
if
we
want
to
do
unidirectional
messages,
for
example,
control
messages
in
the
transport
itself
that
are
not
associated
with
an
RPC,
then
we
have
to
have
some
mechanism
for
managing
credits.
In
that
case
next
slide,
a
number
of
security
issues
have
been
pointed
out.
To
me.
I
Probably
the
most
important
one
is
the
second
bullet
we
don't
have.
The
the
transport
headers
are
completely
in
the
clear
on
the
on
the
fabric
and
there's
no
integrity,
checking
not
that
there
needs
to
be
with
InfiniBand,
but
maybe
there
there
needs
to
be
with
rocki.
Rocki
b2
is
routed,
and
so
I
think
that
it
becomes
more
and
more
important
to
at
least
protect
the
integrity
of
the
transport,
headers
and
headers,
and
probably
also
the
confidentiality
make
them
private.
I
I
think
one
of
the
interesting
ones
that
we
encountered
as
we
were
finishing
up
NFS
over
our
DMA
upper-layer
binding
RFC
56
67
bits
was
the
ability
for
the
two
sides
to
figure
out
if
they'd
actually
sent
more
chunks.
If
the
client
sends
more
chunks
than
the
server
can
handle,
though,
there's
really
no
way
in
the
current
transport
protocol
to
report
that
and
to
have
the
client.
Oh
well,
maybe
I
should
simplify
my
request
and
try
it
again.
I
I
So
what
if
we
got
rid
of
reply
size
estimation,
so
that
the
client
didn't
have
to
do
that?
Well,
the
way
to
do
that
is
to
make
a
mechanism
that
the
server
can
use
to
put
up
the
reply
and
tell
the
client
how
much
how
big
it
is
and
let
the
client
read
it
with
RDMA.
So
I
proposed
that
in
the
and
another
internet
draft
next
slide,
there
are
a
couple
of
other
things
that
we
were
thinking
about
with
RPC
over
our
DMA
version.
Two.
I
The
key
one
I
think
is
being
able
to
extend
the
transport
protocol
because
we
obviously
aren't
going
to
be
able
to
think
of
everything
it
needs
to
do
today.
So
Dave's
written
a
couple
of
IDs
on
that
and
those
are
available
for
people
to
look
at
next
slide.
So
how
do
we
put
these?
How
do
we
realize
these
these
dreams
and
aspirations
next
slide?
So
what
I've
done
is
I
broken
up
the
set
of
work
that
we
probably
have
to
do
into
three
groupings.
These
are
kind
of
orthogonal
with
each
other.
I
I
I
G
I
F
B
So
call
me
unimaginative,
but
I
think
probably
take
it
to
the
mail
list
in
and
with
a
slight
priority
item,
because
you
mentioned
a
bunch
of
things.
The
things
that
I'm
concerned
about
you
mentioned
a
bunch
of
things
for
a
possible
future
work
for
our
DNA
and
and
things
that
are
things
that
would
require
work,
work
or
at
least
collaboration
I,
would
think
for
moving
forward.
So
if
you
prioritize
them
and
give
them
a
listen,
say:
hey
these!
These
are
the
things
that
are
of
interest
for
the
future.
That
would
help
me
on
the
mailing.
I
B
B
E
A
L
Right
now,
I
think
there's
just
plenty
of
flow
well,
reasonably
low
hanging
fruit
in
the
implementations
and,
of
course,
as
part
of
that,
we
will
find
all
kinds
of
minor
protocol
issues
that
should
be
errata
or
the
base
document
you
just
published
so
I
think
there's
there's
plenty
of
work
to
do
there
and
that
work
should
give
us
ideas
of
where
to
go
to
for
working
to
once
we're
ready
for
that.
So.
I
L
I
mean
I
I.
Think
the
point
is
a
new
new
version
of
the
protocol.
Isn't
suddenly
gonna
fix
all
that
low-hanging
fruit
we
have
anyway.
So
to
me
it
makes
sense
to
prioritize
on
that
and
record.
The
lessons
learned
maybe
do
drafts
of
working
to
you
for
now,
without
too
much
focus
on
implementing
and
shifting
it
until
everything
else
is
for
dead.
That
would
be
my
approach,
but
I'm
not
driving
this
so
I'm,
not
the
one
to
decide.
I
I
Yeah
I
mean
I.
I
tend
to
agree
that
there
there's
a
lot
of
room
for
improvement
in
the
implementations.
As
I
said,
there
was
a
long
fallow
period
and
I
think
that
affected
more
than
just
the
Linux
complementation,
during
which
we
could
have
been
improving
the
implementations
and
finding
these
problems
and
that
we
just
weren't
because
nobody
was
working
on
it
and
now
we're
coming
back
to
it
and
you
know
and
the
other
pieces.
I
L
So
I
talked
a
little
bit
about
this
last
year
when
I
had
the
first
draft
out
a
couple
of
weeks
ago
or
months,
but
now
I
don't
know,
I
did
a
second
version
of
that
after
some
feedback
from
date
like
and
not
much
changed,
it
was
a
couple.
Smaller
updates,
the
biggest
visible
changes
I
think
that
discuss
Guzzi
layout
draw
finally
got
published
as
RFC
8
154.
So
at
least
our
dependency
is
stable.
No,
it.
L
Just
the
little
background
slide
against
everyone's
already
seen
this,
so
that
the
point
is
that
until
a
short
time
ago,
if
you
were
talking
about
remote
shared
storage,
it
was
basically
some
flavor
ups.
Does
he
fiber
channel
I
scuzzy?
Some
people
did
share
the
sauce
erase
whatever
and
the
new
kid
on
the
block.
L
So
it
came
out
with
an
argument:
there's
a
fiber
channel
transfer
going
on
and
the
fiber
channel
community,
which
is
supposed
to
be
done
really
soon
and
now
work
on
the
TCP
Transperth
sort
of
an
ice-covered
replacement.
So
people
are
are
eager
to
see
something
like
this
elio
free
Muni
and
as
the
author
of
the
scuzzy
layout
and
one
of
the
people
active
on
Muni
people,
ask
me
if
that
was
possible.
L
Fortunately,
for
us,
depending
on
how
you
want
to
see
it,
there
is
a
document
publish,
that's
called
the
nvme
expressed
as
a
translation
reference
that
even
details
these
mappings.
The
problem
is
that
document
is
pretty
bad
quality
and
out-of-date
and
yeah,
so
that
that
is
actually
the
major
stumbling
block
with
my
draft
is
you
have
want
to.
L
L
And
now
it's
two
days
against
one
christo,
so
I
thought
I'd
get
away
with
informal,
so
I
think
I'm
finally
convinced
to
move
it
over
to
standards
track
and
propose
it
to
the
working
group,
which
will
also
get
me
up
the
work
of
replacing
all
the
RFC
21
19
words,
which
would
be
annoying,
and
then
the
next
major
issue
is:
what
are
we
going
to
do
with
the
skeptic
translation
reference?
Currently,
nvme
is
starting
up
again
to
do
updates
on
that.
N
Thing
that
sounds
like
an
it
for
me
me
reservations
reference
one
three
and
require
that
not
anything
earlier,
as
there
are
some
unfortunate
but
very
important
bug
fixes
in
one
three,
it
turns
out
that
reservations
as
specified
prior
to
1/3
don't
actually
work
the
way
you
want
them
to.
Although
it
is
quite
possible
that
this
layout
doesn't
depend
on
the
things
that
were
broken
so.
N
N
So
that
was
a
joking
version
of
an
unfortunately
serious
recommendation,
which
is
I.
Think
you
need
to
spec
what
you
need
directly
against
Envy
new
one
point:
three.
The
updates
that
are
being
done
to
the
translation
doc
are
being
done
selectively
to
solve
a
very
specific
problem,
which
is
that
independent
of
how
long
the
sky,
zio
command
survives.
Scuzzy
enclosure
services
will
be
with
us
until
the
next
ice
age
and
therefore
that
has
to
have
an
accurate
translation
and
that's
pretty
much
all
they're
working
on.
L
N
L
N
L
Well,
we'll
see
I
think
my
plan
for
now
will
be
to
propose
this
a
standard
strike
and
move
it
to
the
working
group
of
no
one
complaints
with
with
just
minor
review
changes
from
Dave
Novick
for
now
and
then
see
if
I
have
to
go
down
and
remove
the
STL
reference
and
redo
it
or
if
we
can't
get
that
out
to
a
reasonable
ish
enough
shape
and
sit
it
out
or
fight.
Some
Mills.
L
N
L
L
L
So
the
whole
idea
of
this
layout
is
that
our
that,
on
our
server
side
in
the
protis
sense
could
be
the
end.
Yes,
it
could
actually
be
separate
data
service
that
drive
the
HCA's.
We
have
byte
addressable
storage
and
the
broader
sense.
We
can
turn
the
RDMA
model
that
all
the
RMA
storage
protocols
use
where
the
client
registers
the
memory
sends
the
handles
and
the
instructions
of
what
to
do
to
the
server
side
and
then
the
server
side.
L
Does
the
rDNA
read
and
write
operations
upside
down,
because
now
we
have
byte
addressable
storage
from
the
server.
We
can
do
memory
registrations
on
the
server
that
could
be
long
living
so
that
they're
out
of
the
performance
path,
if
you
look
at
argue,
make
performance
numbers
on
on
fast
protocols,
memory,
registration,
overhead
actually
is
the
biggest
overhead
and
the
hall
IO
sequence
and.
L
Of
the
server
does
the
actual
our
DMA
read
and
write
operations
on
the
handle
it
comes
to
the
server,
and
if
we
look
at
how
this
fits
into
a
PMF
S
layout
model,
we
first
start
with
what
is
our
map
NFS
device,
the
device
at
r4?
And
this
is
actually
where
my
current
draft
is
so
the
murkiest
of
the
whole
thing,
because
I
just
had
my
prototype,
you
need
to
come
up
with
something
we
can
standardize.
So
the
idea
is
that
our
device
refers
to
a
domain.
That
is
basically
the
domain
for
the
memory
registrations.
L
So
in
our
team
18
terms,
it
should
map
to
a
protection
domain
in
a
way
to
address
the
protection
domain,
depending
on
the
implementations
that
protection
domain
might
also
be
for
our
DMA
cue
pair
or
nod.
We
can
figure
that
out,
so
our
device
needs
to
tell
a
way
to
reach
a
remote
system
that
it
can
create
one
or
more
cue
pairs
that
go
to
specific
protection
main,
and
this
is
a
bit
of
an
open
issue.
L
So
we
could
use
reuse
in
of
SRD,
make
connections
in
one
form
or
another,
as
an
upgrade
over
connections
used
for
an
emphasis
over
our
DMA
use
connections
that
are
created
the
same
way
as
NFS.
Are
you
make
connections
but
not
actually
used
for
plaintiff
s
IO
or
we
could
use
a
separate
connection
management
protocol
where
we
just
do
an
RDM,
a
cm
and
shake,
which
is
what
I'm
doing
right
now,
but
which,
as
the
caveat
that
we
need
to
have
some
shared
identity
between
the
NFS
connections
and
our
new
site
channel
connection.
L
So
the
layouts
need
to
give
the
client
the
information,
so
it
needs
to
like,
like
all
the
layouts,
it
needs
to
reference,
a
device
that
we
just
talked
about,
which
what
sort
of
apply
the
cue
peers
that
we
could
do
find
a
great
selection
on
that.
Possibly
then
our
memory
registration
handle
our
key
and
InfiniBand
terms.
S
taking
I
work
terms,
then,
because
we
don't
really
want
to
repeat
the
mistakes
of
the
icer.
L
We
also
want
an
offset
into
the
memory
registration
instead
of
assuming
it's
always
zero
to
file
relative
offset
in
the
layout
and
lengths
of
the
layout,
which
is
that
later,
who
lusts
to
or
thinks
attorney.
If
your
layout
anyway,
the
one
thing
I
want
to
keep
from
the
skeleton
block.
Layouts
is
the
possibility
of
client-side
copy
and
write
processing
so
for
a
given
range
in
a
file
met
by
layout.
I
want
to
be
able
to
have
separate
destinations
for
reads
and
for
writes.
L
N
L
This
functionality
I
really
want
to
keep
for
the
way
out.
But
to
me
it
seems
like
we
could
do
this
in
a
simpler
way
by
just
having
a
memory,
registration
plus
offset
separately
for
reads
and
writes
in
the
main
layout.
Instead
of
having
another
data
structure
that
basically
dublicate
s--
the
way
layouts
are
used-
and
this
is
already
something
I
asked
myself-
wouldn't
do
in
the
block
level
at
work.
N
L
And
now
the
next
interesting
thing
when
talking
about
persistent
memory
of
sorts
is
how
do
we
flush
caches?
How
do
we
posted
rights
if
we're
going
over
PCIe,
so
our
team,
a
write
operation
just
just
to
look
at
one
of
the
two
prototypes
I
do
where
I
go
to
bar
on
a
PCE
device?
It's
all
posted
rights
and
you
need
to
flush
them,
but
it
would
be
pretty
similar
if
you
have
say
a
battery
pack
DRAM
on
the
main
memory
bus.
If
that's
a
cache
mapping,
we
might
have
to
flush
caches
as
well.
L
So
there's
interesting,
cache
flushing
requirements
depending
on
what
your
actual
fight
addressable
storage
is
in
the
backend
and
for
some
other
interconnects
like
like
non-cash
mappings
on
the
memory,
bus
or
upcoming
kishka
here
and
interfaces
there's
about
15
to
choose
from
right.
Now,
none
of
them
has
more
than
three
vendors
supporting
them.
L
So
we're
now,
what
we're
doing
this
doesn't
block
layout
is
that
cache
flushing
is
required
is
has
to
be
done
by
layout,
commit
and
every
what
right
is
followed
by
a
layout
commit
eventually
the
flakes
files.
People
realize
that
this
creates
a
nasty
bottleneck,
because
now
every
right
eventually
needs
to
go
through
the
MDS
at
layout,
commit
time
and
if
you're
doing
synchronous.
C
L
Which
people
like
persistent
memory
for
that
means
for
every
round-trip?
You
have
another
round
trip
to
the
MPS.
So
what
we
want
to
do
is
do
the
same
trick
that
flex
flex
files
did
is
make
the
layout
commit
optional.
So
if
we
know
we
don't
have
to
flush
at
all,
so
it
doesn't
have
to
be
a
layout
commit
for
any
print
and
if
we
get
a
transport
that
supports
the
our
DMA
native
flush
operation,
so
that
was
some
talk
of
it.
Currently
work
is
going
on
in
the
IB
ta,
but
there
are
closed
organization.
N
Matters
a
visit,
a
board
or
actually
yeah
I,
be
ta
will
do
it
I
be
ta.
Does
the
crucial
question
here
is:
what's
gonna
land
in
the
verbs
and
one
of
the
verbs
point
and
when,
when
is
when
is
the
verb
for
flush
going
to
be
support
across
all
the
usual
suspects
and
I?
Don't
I
don't
have
this
out
of
his
blue
eyes
and
we
have
anybody.
Have
visibility
into
what's
going
on
with
the
fabrics
verbs
stuff?
I
L
But
the
point
is
we:
we
actually
need
all
three
options
right.
We
need
the
option
to
layout
commit,
we
need
the
option
to
flush
and
we
need
the
option
to
do
nothing,
because,
if
you're
doing
things
like
the
copy
and
write
processing
at
a
the
earlier
order
or
hole
filling
same
way
as
as
block
does
that
we
will
need
the
layout
commit.
Eventually,
because
that's
something
you
will
need
the
MPs
involved
to
manage
the
files
to
me.
L
L
Okay,
so
I
think
yeah.
It's
just
summary
of
open
issues
which
there
are
a
lot
of
connection
model
connection
management.
Do
we
need
the
extents?
How
do
we
support
our
DNA
level
flush,
especially
at
a
point
where
we
don't
know
how
it's
going
to
look
like
yet
so,
hopefully
we'll
have
it
before
making
too
much
progress
on
it.
And
the
other
thing
is:
what
kind
of
hints
do
we
need
to
kill
declined?
How
to
manage
the
layouts,
and
this
is
kinda-
depends
on
how
expensive
it
is
to
get
the
layout.
L
So
right
now
we
were
just
talking
about
what
people
traditionally
called
persistent
memories,
so
your
memory
is
always
byte
addressable
and
just
there
and
we
get
a
memory
registration
to
it,
which
is
way
more
expensive
than
I/o,
but
not
crazy,
expensive,
now
think
of
a
byte
addressable
device.
That
is
not
really
the
storage
device,
so
thang
nvme
controller
memory
buffer.
So
if
we
have
a
model
where
each
client
has
its
own
region,
an
nvme
controller
memory
buffer,
so
it's
just
a
piece,
a
key
bar,
that's
not
persistent
by
itself.
L
So
when
we
give
out
a
read
layout,
basically
we
need
to
do
an
nvme
read
into
its
own
controller
memory
buffer,
which
is
XO,
io
@
layout,
yep
time
very
fast
at
I/o,
because
it
doesn't
go
over
a
PCI
bus,
but
we
still
have
to
do
it,
and
in
that
case
we
want
the
client
to
get
as
big
as
possible.
Layouts
and
don't
just
do
like
the
current
way.
Things
like
the
Linux
clients
get
layouts
just
when
they
need
it
and
keep
forgetting
them.
L
Similar
on
on
the
commit
side
is
like
we
could
do
all
this
I/o
into
C
and
B,
and
then
our
layout
commit
operation
or
possibly
even
our
DMA
flash
would
issue
the
actual.
You
could
write
it
back
to
the
backing
device
which,
for
some
for
some
future
memory
technology
devices
might
be
the
right
thing
to
do
in
an
S
occur
at
a
symmetric
way.
So
your
reads
or
normal
byte
addressable
reads,
but
your
writes
might
have
explicit
commit
semantics,
and
that
would
it
fit
in
very
well
with
this
model
too.
B
A
H
C
Actually,
according
to
the
rules
of
authorship,
trondheim
should
be
first,
since
he
did
most
I'll
fix
that
on
the
edit.
So
what
this
talk
is
about
our
a
set
of
different
ideas
that
we've
been
banishing
around
of
what
we
want
to
see
happen
so,
for
example,
scale-out
and
replication.
We
want
to
I'm
gonna,
but
I'm
gonna
read
from
these
slides
that
I
got
in
this
morning
after
breakfast,
and
so
you
know
that
yeah
we
want
to
be
able
to
replicate
data
when
you
sing
Alice
Lee,
a
couple
of
flex
file
system
and.
C
So
the
so,
what
we
want
to
be
able
to
do
is
when
we
migrate
data.
We
want
to
be
able
to
have
the
client
tell
us
or
to
tell
a
data
replicator
what
has
been
moved
already,
such
that
the
data
replicator
doesn't
have
to
move
what
the
client
has
been.
Writing
alright.
So,
right
now,
when
we
have
the
data
replicator,
it
has
to
do
the
entire
file,
but
the
clients
already
moving
some
of
that
or
is
effectively
touching
it
anyway
dirtying
those
bits
and
if
it
could
send
out
these
parts
of
the
files
have
change.
C
So
there
there's
two
points
in
here
for
service
of
quality
of
services.
We
want
to
be
able
to
do
QoS
we
want
to
have
add
features
to
allow
the
MTS
to
communicate
to
the
client
that
there
are
some
resource
limits
and
the
big
important
thing
is
we
want
to
be
able
to
change
it
without
recolor
layouts
layout
recall,
is
very
expensive
for
us.
It's
going
to
be
expensive
for
other
people
too,
and
you
know
we
have
a
list
of
pie-in-the-sky
here's
what
we
wanted
to
limit.
C
The
second
point
on
here
is:
we
have
the
problem
of
snapshotting
when,
in
with
Flex
house,
when
you
you
don't
have
a
control
protocol
to
the
storage
device.
So
if
you
want
us
to
take
a
consistent
snapshot,
you
have
to
basically
ask
the
client
to
stop
the
writes
so
that
it
will
queue
them
up
in
memory
so
that
you
can
have
a
consistent
view
across
the
multiple
storage
devices,
and
so
that's
one
of
the
things
we're
looking
at
pulling
into
the
working
group.
C
It
could
I
mean
it
it's
just
the
the
the
specific
part
that
flex
clause
is.
You
have
to
address
it
through
quiescing
in
the
client,
whereas
with
other
ones,
you
can
do
it
with
pausing
the
I/o
on
the
storage
device
itself
right.
So
a
clustered
file
system
like
say
on
tap,
can
tell
the
storage
device
now's
the
perfect
time
to
take
the
view,
because
it
has
the
back
channel.
C
C
C
C
L
Know
it
too
well
either
and
that's
why
I
wanted
to
trick
mine
to
it.
But
it's
apparently
a
new
local
hypervisor
to
VM
or
VM
to
VM
protocol,
originally
designed
by
VMware
picked
up
by
some
Linux
people
and
they've
done
an
NFS
transferred
over
that's
not
specified
anywhere,
which,
by
the
way,
should
really
be
a
document
in
the
working
group
and.
I
So
the
the
V
sock
idea
is,
you
know
they
find
the
amount
of
network
configuration
required
for
a
guest
to
be
onerous,
and
so
they
want
to
give
guests
a
a
permanent
B
sock
address
of
three
and
the
hypervisor,
a
permanent
B
sock
address
of
one
or
two
I
think
it
is
so
that
when
you
bring
up
a
guest,
you
actually
don't
have
to
you
don't
have
to
include
a
network
device.
You
don't
have
to
include
any
kind
of
IP
configuration.
V
sock
just
works.
I
I
Their
initial
modeling
was
that
the
NFS
physical,
durable
storage
would
be
on
the
host
that
at
hosts
the
guests
in
the
night
asked
them.
How
well
a
house
house
live
migration,
gonna
work
and
then
the
story.
The
story
changed
because,
obviously
the
you
know
as
soon
as
you
move
that
VM
to
another
host,
it's
going
to
see
different
file
handles
the
the
lock
and
open
states
going
to
be
gone,
all
sorts
of
all
sorts
of
problems.
So
now
what
we're
talking
about
is
the
diagram.
I
What
you
see
in
front
of
you,
which
is
host
proxy
so
on
the
host?
It
wouldn't
provide
the
actual
storage,
it
would
provide
an
NFS
gateway
service,
and
that
would
point
at
the
actual
storage
somewhere
else.
So
when
a
when
the
guest
is
is
live
migrated
to
another
host.
That
host
proxy
would
be
aware
of
where
the
storage
for
that
for
that
guest
resides,
and
it
would
allow
a
transparent
transition
to
the
guests
storage
that
was
Jeff,
leaver
and.
N
No
all
right
so
real
strong
message
to
anybody
working
on
this
go
talk
to
the
container
folks,
because
they've
been
fighting
the
problem
that
is
being
created
here
for
a
number
of
years
and
are
have
made
some
of
the
progress
on
it,
be
ashamed.
Shame
to
have
treatment,
solution,
solution,
frameworks
for,
in
essence,
when
container
start
out
they
have.
They
have
a
variant
of
this
problem
in
there
that
can,
and
that's
not
not
alive.
Migration
problems
are
shut
down
and
restart
problem.
N
You
shut
them
in
here
down
a
host
day
and
we
started
on
host
B.
All
of
its
resources
are
all
of
its
OS
resources.
Are
we
initialized,
which
means
no
persistent
storage
and
that
sucks,
if
you're,
trying
to
actually
do
something
useful,
they're
a
long
way
towards
solving
it?
A
lot
of
stuff
is
working.
There's
almost
certainly
some
lessons
we
learned
here
and
if
that
framework
can
be
reused,
suppose
you
reinvented
them
even
better.
N
Well
loud
mumble,
individual
processes,
they
were
black
again
strong
recognition
of
your
processes
is,
if
you
think
you
want
to
migrate,
it
put
it
in
the
container
and
solve
the
problem
for
containers
and
for
containers.
See
previous
comment.
An
awful
lot
of
progress
has
been
made
on
persistent
storage
for
containers
and
having
it
survive
in
container
moves
hosts.
C
I
F
C
I
N
C
So
some
miscellaneous,
when
we
have
an
open
or
return
to
either
an
open
state,
ID
or
an
open
state,
ID
and
a
delegation.
Why
do
we
need
both
so
decided?
An
open
flag,
two
specified
like
a
delegation
or
an
open
state
idea
of
the
delegation,
is
not
available
right.
Just
an
optimization
reader
really
really
hates
it.
I
really
hate
it.
Every
time
I
implement
it,
because
you've
got
to
keep
track
of
the
cookies
are
persistent.
I
C
C
C
So
we
also
want
to
I,
know
Chuck.
We
were
talking
about
this
last
time
we
met.
We
want
to
add
into
some
annotations
the
ARCA
sealer
tracing
support,
so
in
doing
supportability
you
want
to
take
an
event
generated
up
in
the
client
or
in
you
know,
in
the
application
down
to
the
client
over
to
the
drop.
B
Just
just
for
the
record,
because
you're
like
reminding
me
of
stuff
from
the
1980s,
so
the
reason
we
here
is
the
way
it
is
is
because
to
make
it
other
than
that
is
really
freaking
hard
would
require
and
to
make
it
stateful.
It's
a
shared
metadata
state
sharing
across
all
the
clients
and
that
therein
lies
insanity,
so
so
so
that
that's
the
reason
there
was
no
obvious
answer
to
the
stateless
solution
of
redo.
It
was
always
sort
of.
A
I
C
So
the
reason
why
so,
actually,
the
reason
why
the
compound
tags
aren't
appropriate
for
this
is
that
compound
tags
are
not
fixed
in
length
right.
So
if
you
want
to
optimize,
for
example,
reader-response,
you
have
an
issue.
So
if
you
add
a
tap,
give
you
add
in
a
new
field
for
the
the
trace
it's
at
fixed
size
and
allows
you
to
read
the
buffer
in.
I
C
I
I
I
I
D
I
H
N
K
C
C
F
Okay,
so,
as
Beebe
said,
you
know,
we've
been
doing
a
lot
of
things
that
we're
not
in
our
charter,
we're
doing
some
useful
things
and
I
feel
I.
Think
most
people
feel
that
the
working
group
needs
to
continue
doing
the
sorts
of
things
that
has
been
doing
and-
and
it
is
a
fact
that
all
these
things
are
outside
the
current
charter
and
sure
I
think
that
means
the
current
chart
needs
to
change.
So
we
need
to
come
up
with
a
post
charter.
F
It
says
continual
look
more
or
less
along
the
current
path
and
if
anyone
thinks
that
it
needs
a
change
of
direction,
we
should
discuss
that
something.
You
need
charter.
The
word
group
can
live
with
and
that
is
acceptable
to
the
ad
and
to
the
is
G
now
be
nice
to
have
some
of
the
milestones
to
working
I
had
discussion
in
the
BP
a
couple
days
ago,
I
said:
well,
sometimes
people
say
well,
you
have
doesn't
have
this
long
list
of
milestones.
I
don't
have
a
long
list.
F
Around
for
years,
right
next
slide,
so
I've
been
I've
been
reading.
The
word
grew
pleased
list,
I've
been
putting
forth
a
number
of
iterations
of
a
chart.
Drat
drat
well,
not
for
there's
a
milestones
draft
and
current
issues.
I
know
with
the
with
the
text
I
have
is
Chuck's.
Has
an
issue
he's
with
the
virtualization
man
to
the
text,
I.
F
Think,
given
the
discussion
we've
had
this
meeting
I
think
maybe
he
and
I,
or
he
will
come
up
with
what
he
would
like
to
see
their
question
we
at
times
we
realized
that
the
kind
work
that
tom
is
doing
for
flex
files
needed
might
mean
a
bullet
to
the
Charter,
but
so
far
we
haven't
come
up
with
one.
He
has
an
idea
that
they
should
also
come
up.
F
F
Okay,
we
need
a
chart.
I
haven't
I,
have
a
draft
chart
proposal.
We
probably
need
to
get
to
a
real
charter
closely.
We
new
agreement
on
the
broad
outlines,
so
anyone
speak
up.
If
you
think
we
need
more,
stricter
maintenance
focus
charter.
I
think
Spencer
had
some
some
comments
in
that
regard.
Maybe
I
don't
know
if
it
changes
his
mind
or
not
anyway.
If
someone
needs
to
think
we
should
go
in
that
direction.
Let's,
let's.
Let's
have
that
discussion.
If
there's
an
area
of
extension,
we're
missing.
F
Let
me
know
it's
important
to
initiative
in
addition
to
all
the
other
stuff
we've
been
discussing
now,
let
me
know-
and
you
think
draft
is
significantly
wrong
in
the
other
way.
Let
me
know
also
given
this
is
a
medium.
This
I
can
count
not
seven
people.
There
are
other
people
who
may
need
to
comment
and
they
should
comment
them
on
the
list
and
I
know
people
like
the
site
knits
and
have
complaints
about
various
things,
but
you
can
do
that,
but
we
need
to
focus
on
the
basic
messages
is
anything
wrong
in
the
messages?
F
That
be
approved
by
other
people
than
us
other
people
than
ask
the
people
who
know
what
do
you
know
what
they
want,
but
anyway
other
people
have
a
voice.
So
far,
no
one
has
been
saying
Brandi
that
veto
pen.
We
have
to
make
a
proposal
and
see
what
happens
if
someone
doesn't
like
it.
We'll
discuss
that
now.
Looking
at
the
current
proposal,
which
I
can
go,
I
have
slides
for
it.
Otherwise
people
would
read
it.
Ok
with
it.
That's
ok,
so
the
myth
is
a
maintenance
section.
F
That's
key
did
a
lot
of
the
stuff
we've
been
doing
like
RFC
7931
and
the
rDNA
dis
documents.
That's
the
kind
of
maintenance
we've
been
doing
and
which
is
different
than
the
maintance.
That's
the
current
charters,
more
restrictive.
It's
an
extension
section,
I
think
that
should
be
OK
in
general,
given
that
we've
published
successfully
RFC
8178
just
a
few
days
ago.
As
far
as
specific
extension
areas,
food
insecurity
we'll
just
have
to
see
how
that
goes.
F
B
F
F
That,
basically
was
essentially
what
was
in
RFC,
35
30
and
all
both
of
that
was
approved
by
the
ice-t
75
30
was
approved
by
is
G,
it
made
sense,
then
it
doesn't
make
sense
now,
but
look
at
it
see
GE.
This
is
a
total
mess.
So
anyway
we
have
we
somehow
puii.
We
have
some
some
problem
with
the
security
sector.
We
don't
know
what
it
is
and
they
haven't
been
fair,
very
forthcoming
about
anything
other
than
they.
F
Thirty
to
prove
that
7532
prove
that
this
is
just
want
to
prove
that
and
now
we
get
now
and
they
say
they
don't
like
it.
So
so
in
the
sections
in
spend
that
section
and
one
of
the
possible
things
that
I've
referred
to
as
more
effective
responses
to
security
challenges
that
that
wasn't
me
Chuck's
text
and
I
think
that
that
will
well
one
possible
way.
We
could
do
that
and
say
that
geez.
These
is
to
you.
Expectations
are
what
our
may
reflect
those
security
challenges.
F
What
we
should
have
done,
we
might
have
done
in
the
Security,
considers
its
getting
rid
of
the
fact
that
it's
formless,
that
the
idea
was
the
necessary
to
respond
to
one
specific
sector
criticism
and
find
to
be
enough
to
satisfy
them,
but
would
it
it
appears
that
some
of
the
people
in
the
secured
directed
think
that
somehow
we
NFS
is
the
in
officially
nfsv4
is
the
the
IETF
internet
approach,
the
Fosse
area?
But
it's
not
really
it's
basically
a
land
protocol.
That's
been
a
land
protocol
and
mmm-hmm.
O
I
F
First
I
was
thinking
of
possibly
I'm,
saying
first
I'm
to
put
something
in
the
Charter
I
think
that's
there.
Secondly,
I'm
wondering
if,
if
we'll
get
to
pushback
from
them
and
then
if
then,
what
would
we
put
in
an
IDs
to
address
that?
So
that's
conditional
all
right,
so
one
of
the
things
that
they
might
want
I'm
trying
to
figure
out
what
they
might
be
be.
C
F
F
People
who
use
Kerberos
typically
do
not
use
it
with
encryption
and
various
places
in
our
lives
in
our
security
considerations
and
say:
oh
gee,
when
you're
doing
this,
you
might
want
to
use
protest
integrity
while
you're
doing
that,
okay
sure,
but
if
you're
concerned
about
security,
you
would
address
the
fact
that
all
your
data
is
in
the
clear
to
be
modified
or
your
applications,
they've,
modified
and
and
looked
at.
You
know
if
you're
concerned
about
security,
it's
all,
but
most
people
aren't
so
they're
there.
F
It
is
okay,
so
that's,
but
that
was
something
I'm
sure
the
security
director
would
be
like,
but
I,
don't
think,
there's
enough
interest
in
the
working
people
to
do
that,
but
anyway,
next
slide.
Another
thing
we
might
do
is
figure
how
you
know,
there's
a
reason
that
people
don't
use
encryption
and
that
is
performance
and
when
I
mentioned
this
to
the
people,
the
security
director,
their
response
was
oh
well.
Well.
Well,
people
are
always
concerned
about
that.
We
tried
that
with
HTTP
people
were
worried
about.
F
They
have
no
idea
that
the
scale
of
our
performance
challenges
and
I
don't
know.
I
didn't
want
to
get
into
a
big
argument
about
it.
But
that's
the
issue
right
now
we'd
like
if
we
want
our
interested
in
its
in
securing
the
data.
It
has
to
be
done
by
hardware
and
that's
probably
at
something
to
do
alone,
but
that's
an
area
we
might
explore,
but
that
couldn't
be
done
in
the
short
term.
A
F
N
B
M
N
Black,
let
let's
take
security
now.
Can
we
go
back
back
the
previous
slide?
So
if
I,
let's
see
so
I'm
coming
I'm
coming
at
this
new,
which
means
I
haven't
seen
all
all
all
all
the
detailed
discussion
and
context
is
not
gonna.
Stop
me
from
saying
saying
some
things
Dave
as
I.
Listen
as
it
strikes
strikes
me
to
you
and
I
have
been
here
before
on
internationalization
we're
an
essence.
Once
upon
a
time
the
isg
kicked
draft
back
to
us
and
said
the
I
89
section
is
a
joke.
Rewrite
it
and
I.
N
Think
what's
happening
is
some
variant
of
that.
Where
we're
essentially
being
told
the
security
considerations
section
of
75
30
is
a
joke
and
what
is
probably,
let's
see,
what
is
probably
sufficient
is
a
doc
on
on
security
that
essentially
starts
out
to
rewrite
the
7532
security
considerations.
Now
one
of
the
interesting
things
that
might
help
here,
although
it's
it's
a
double-edged
sword
in
the
transport
area,
we've
managed
to
come
up
with
a
disciplic
ability
distinction
between
the
public
capital,
I
internet
in
general
and
controlled
environment.
N
That
said,
I
don't
know
where
the
security
area
is
going
to
be
on
this,
because
it's
quite
possible
to
come
back
and
say
that
that
your
security
has
to
be
for
the
public
capital
I
Internet
all
stop
full
stop,
but
I'm
going
to
suggest
here
is
I.
Think
what's
I
think
what
would
respond.
A
security
area
would
be,
in
essence,
signing
up
to
do
a
draft
that
rewrites
the
security
considerations
section
of
75
30,
particularly
not
even
the
archaeological
dig
and
said
well
it
acts
was.
N
I,
don't
know
that
the
supposed
security
but
I
would
that
would
certainly
be
a
if,
if
you
want
to
do
something
that
will
in
essence
convey
the
fact
convey
the
notion
that
we
have
a
clue
to
the
security
area
signing
up
for
a
draft
that
we
write.
Seventy-Five
thirties
security
security
considerations
and
update
seventy
five.
Thirty
with
the
rewritten
considerations,
would
would
be
a
solid
thing
to
do.
Okay
noted.
F
All
right
now
milestones
yeah
I
in
previous
iterations
of
these
slides
that
we
need
some
milestones
and
Chuck
said
well.
You
have
to
say
why
well
I've
had
to
come
up
with
why
you
have
to
have
to
make
clearly
I
asked
you
where
we
are
going
in
the
near
term
and
that's
I
think
where,
where
I
think
we
need
to
do
so
right
now
we
have
only
one
milestone
as
you'll
see
later.
Okay,
so
well,
that's.
F
N
So
that
sounds
like
us,
like
a
start,
with
hat
with
blue
dot
on
head,
what
we've
typically
done
in
done
in
a
TS
vwg
and
it's
work.
It's
working
quite
well
is
for
every
item
of
work
that
has
a
draft
as
a
mas
there's,
there's
a
mouse
on
right.
There's
a
mouse
on
written
written
against
that
draft
and
the
Charter
should
be
anticipating
some
some
drafts,
and
if
you
know
what
the
drafts
are,
gonna
be
or
what
you
think
they're
gonna
be
milestone
month.
Milestone
per
draft
is
a
straightforward
way
to
deal
with
it.
N
F
Okay,
okay,
so
this
is
possum
milestone.
Some
of
those
are
we're.
Not
clear
about
argument
will
be
if,
if
we
decide
to
go
with
making
some
of
some
some
of
the
things
Chuck's
decided
as
as
working
through,
perhaps
they
would
have
milestones
that
and
maybe
the
the
thing
that
David
suggested
through
security
might
have
track
and
as
according
to
some
text
that
Spencer
suggest
we
have
the
option
to
add
later.
Okay,
I
think
that's
key,
pretty
much
that
all
right,
we
need
plan.
We
need
to
get
figure
out
exactly
how
long
this
take.
B
F
F
All
right,
so
all
right!
This
is
basically
you
know
a
power
punctual
eyes,
this,
the
existing
draft
and
basically
yes,
the
ayat,
if
standard
for
file-sharing.
But
it's
not
capital,
I
internet
as
David
Senate,
and
you
know
we're
chaired
to
maintain
the
existing
specifications
and
as
Chuck
suggests,
and
the
ONC
components
as
RPC
XDR
and
RPC
set
to
assess
and
also
they're
working
to
develop
extensions
and
have
some
current
extensions
and
some
I
don't
think
any.
B
It
covers
nicely
the
things
we
were
covering
today
in
the
discussions,
including
the
nvme,
the
RDMA
stuff
and
the
maintenance
work,
that's
being
done
on
the
specifications
that
we
have
here.
So
this
wording
tip
to
me,
has
been
on
the
on
the
mail
list
and
I
see
heads
nodding
up
and
down
I'm,
seeing
one
in
person
nodding
over
here
for
stuff,
but
he's
he's
on
it
he's
on
it,
he's
on
it
too.
So
this
is
great.
Okay,
next.
F
F
F
N
The
black
middle
bullet
look
at
Spencer
as
I
say
this,
and
he
can
revise
my
remarks
for
me
in
the
past,
I've
been
told
that
there
are
certain
ADEs
who
get
very
excited
about
about
brand
new
BCPs,
so
that's
best
current
practice.
I
would
recommend
there,
for
the
third
line
of
the
middle
bullet
simply
be
reduced
to
publication
of
RFC
s
that
provided
editorial
modification.
And/Or
technical
update
just
just
take
out
best
practices
lest
someone
we
we
miss,
read
as
best
current
practices
and
get
too
excited.
O
Spencer
Dawkins
responsible
area
director,
you
can
always
punt
that
you
can
always
put
this
question
to
the
eye
ASG,
because
the
IHG
can,
including
me,
can
make
determinations
on
document
tracks
and
stuff
like
that.
Even
during
our
evaluation,
we've
got
one
that's
banging
around
right
now,
that's
you
know,
I
mean
the
answer.
Is
you
know,
shoot
high,
because
it's
easy.
O
N
F
All
right,
so
the
another
part
of
the
draft
is
that
we're
doing
extensions,
because
before
is
designed
to
allow
in
extensions
and
mention
that
and
mentioned
some
of
the
ONC
protocol
components
can
all
have
versioning
framework
and,
for
example,
if
we
need
something
added,
we
will
add
it.
Some
of
the
work
that's
been
discussed
before
ethic
and
fundamental
everyone
to
assure
people
that
working
group
was
discuss
these
and
make
sure
they
have
adequate
review,
which
they
should
have
and.
F
Now
next
I
guess,
and
then
we
have
a
list
of
things
that
the
working
group
has
come
up
come
up
with
and
we
had
discussion
of
how
to
categorize
these
what
maxify
end
of
his
performance
on
advanced
fabrics,
new
storage
technologies.
These
are
things
that
happening
as
we
speak,
and
if
we,
if
we
don't
respond
to
them,
what
would
be
left
the
hand
facility
for
management
of
benefits,
access,
storage
and
large
server,
virtualization
air
air
environments,
and
some
of
that
gets
to
some
of
the
stuff
that
Tom
mentioned
and
more
effective
responses
to
severe
jobs.
F
So
that's
what
I
have
currently
and
Massa.
This
is
a
single
milestone.
I
have
working
group
last
call
for
migration
issues
that
probably
is
gonna
be
an
informational
might
not
might
not
even
be
published.
We
don't
know
why.
Whether
it
really
needs
to
be
published,
but
I
think
I
want
to
have
to
have
a
final
discussion
of
that
of
that
of
that
document,
to
make
sure
that
we
nailed
that
issue
anyway.
That's
it.
B
So
just
going
back
David,
you
have
comment
before
you
know:
David
black
yeah,
no,
so
so
I'm
I,
this
is
support,
said
I'm
liking
here,
so
the
general
section,
as
mr.
Novik
put
together
in
a
bullet
eyes
forum,
the
general
section,
the
made
the
description
of
the
need
for
maintenance
and
then
the
work
that's
being
done.
Currently
that's
under
that.
We,
which
has
been
discussed
today
on
extensions
and
just
the
motivation
behind
them
to
me
makeup.
B
What
is
the
body
of
the
proposed
new
charter
for
the
group
and
I
personally,
don't
find
anything
controversial
in
there
because
of
two
things.
It's
covering
the
fact
that,
yes,
if
we
are
a
working
group,
still
formed,
we
are
here
in
part
to
maintain
the
existing
standards
and
there
is
current
work
going
on
the
work
that's
going
on
is
very
much
framed
as
extensions
to
the
body
that
already
exists.
B
There's
a
we're,
not
we're
not
coming
up
with
a
new
working
group
area
or
definition
that's
going
to
spin
out
or
something
so
it's
well
within
the
framework
of
maintenance
and
response
to
not
only
technology
but
I.
Think
one
of
the
things
about
security
by
the
way
is
that
this
working
group
has
been
around
for
a
very
long
time
and,
as
we
have
changed,
how
we
think
the
security
people
are
changing
too
so
responding
to
security,
as
that
changes
over
time
is,
of
course,
to
be
to
be
part
of
our
lives
in
this
working
group.
B
O
G
O
Problem
we'll
go
back
to
1986
or
whatever
you
know
whatever
it.
Wherever
the
model
came
from,
you
know,
it'll
be
awesome,
so
I
would
out
you
know.
That's
you
know
that
that
stuff,
like
me,
is
it's
like
a
no-brainer
at
any
point
and
if
somebody
you
know,
did
somebody
came
up
with
a
plan,
it
wasn't
in
charge.
Yeah
that
wasn't
in
a
current
charter.
I
would
say:
I,
don't
you
know
I,
don't
care
this
uncorrect
charter.
This
is
the
right
thing
to
do
for
working
group
things.
O
B
B
Yeah
cuz
I.
Let
me
let
me
be,
let
me
be
precise,
it
its
existing
work
that
has
been
under
development
for
years
sure
so,
there's
maintenance
work
being
at
some.
Some
of
the
comments.
Some
of
the
comments
for
our
DMA
were
I.
Would
today,
I
would
put
in
the
category
of
maintenance
clarification,
but
then
it
was
also
some
discussion
from
Chuck
about
things.
We
would
like
to
do
differently,
given
what
we
know
now
and
those
would
be
extension
so
we
covered
both
today.
So
it's
it's
under
both
parts.
O
O
C
O
B
I
believe
and
I'm
the
I
think
thanks.
So
when
I
was
talking
to
Dave
I
was
said:
let's
push
off
the
milestones,
because
I
just
want
the
the
Charter
text
to
be
to
be
encompassing
of
the
work
and
let's
get
the
milestones
to
reflect
the
specifics
underneath
the
Charter
such
that
this
is
the
things
that
are
actually
the
deliverables
against
the
Charter
spec
and
that
because
I'd
rather
not
like
I,
think
one
time
we
had
to
draft
charter
SPECT
years
and
years
ago.
B
That
was
getting
like
way
too
specific
and
we
were
sort
of
like
tying
our
shoelaces
together,
the
next
time
we
had
a
discussion
about.
If
something
we
had
to
do
so,
the
I
like
to
charter
the
way
it
is
the
way
the
tape
has
come
up
with
it.
And
then
let's
have
the
milestones,
focus
on
the
the
work
items
and
each
work
item.
Each
area
lead
to
come
up
with
a
set
of
milestones
that
reflects
the
stuff
that
they
need
to
do
near
term
medium
term,
so
sounds
good
and.
O
O
O
B
B
B
O
B
A
B
O
O
Exam
I
think
I'm
good
if
I
was
going
to
say
something
nice
about
you
all,
which
is
probably
a
good
thing
for
me
to
do.
At
this
point,
I've
gotten
I've
been
really
impressed
with
the
quality
of
the
work.
That's
come
out
of
this
working
group
and
really
didn't
really
appreciate,
really
appreciate
you
all
you.
This
working
group
produced
over
a
period
of
time,
of
course,
but
you
Pro
do
you.
This
working
group
reduced
most
of
the
RFC's
that
were
published
in
the
last
IETF
cycle,
auto
transport.
O
B
N
Were
but
I
think
I
mostly
got
up
to
plus
form
what
you
said:
BP,
which
is
I
like
the
Charter
text.
One
milestone
is
not
enough,
but
figure
out
the
milestone,
so
that
makes
sense
based
on
drafts
and
I.
Think
also
probably
ought
to
take
the
discussion
here
about
a
draft
to
go
rewrite.
Seventy
five,
thirty
security
considerations,
section
two
of
the
list
and
see,
was
to
see
if
it
still
still
makes
as
much
sense
in
a
week
from
now
as
it
did
as
it
did
in
the
last
thirty
minutes.
N
I
would
also
want
to
say,
with
my
blue
dot
hat
on
as
one
of
Spencer's
chairs
of
chairs.
Another
working
group
Spencer
has
been
very,
very
flexible
about
milestone
additions
date,
change,
etcetera
in
particular.
It's
I
would
not
view
a
date
put
on
a
milestone
in
a
recharter
Draft
as
anything
more
than
a
plausible
expectation.
Guess
it's
not
a
it's,
not
a
contract
with
the
iesg.
Lord
knows,
lord
knows
how
many
times
I
revise
from
of
my
milestones.
O
Guys,
mister
is
actually
going
to
point
out
that
I
approved
seven
milestone
web
base
yesterday
for
David,
so
he
so
you
know
use
that
as
you're
trying
to
calibrate
what
you
think
flexible
means
so
I
think
that's
fair.
The
other
thing
is
I'm
comfortable
with
putting
the
my
putting
the
mouse
at
the
milestone
and
dates
forward
that
the
group
is
actually
working
on
now.
O
If
you
know,
if
you
guys
have
other
stuff
in
mind
that
you're
not
going
to
you're,
not
gonna,
be
working
on
first
I'm
fine,
with
going
forward
with
a
smaller
set
of
milestones
with.
You
know
that
basically
don't
cover
everything
that
you're
thinking,
but
that
you
use,
but
you
use
the
limited
set
of
milestones
to
kind
of
direct
the
work
of
the
working
group
and
I.
It's
always
made
sense
to
me:
okay,
cool.
G
B
Say
is
there
any
additional
items
that
anybody
would
like
to
bring
up
and
discuss?
I
think
I
gonna
get
the
minutes
out
identifying
some
people
who
need
to
get
some
stuff
out,
and
it's
anime
list
right.
So
we
have
to
follow
up
I
mentioned
before
for
the
people
I
present
today.
I
would
appreciate
it
if
you,
if
you
took
to
the
mail
list
and
not
just
my
minutes,
are
always
pretty
sparse.
B
If
you
took
to
the
mail
list-
and
you
know
kind
of
summarized,
you
know
this
is
where
I
this,
but
I
walk
out
of
the
room
with
this
is
my
next
steps,
such
as
they
are
like
for
you
just
saying
so.
You
know
I'm
working
with
Spencer
to
get
the
last
call
going
on
draft
fly,
there's
no
more
feedback.
Thank
you
very
much,
and
that
will
just
let
everybody
else
know
what
we've
been
covering
in
this
room.
Okay,
that's
it
going
once
going
twice.