►
From YouTube: IETF102-NFSV4-20180716-0930
Description
NFSV4 meeting session at IETF102
2018/07/16 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
A
A
A
A
C
D
E
A
A
A
E
A
B
A
A
You
say
is
a
contribution.
Thank
you
very
much
all
right
agenda.
No,
you
can't
deduct
it
on
taxes,
nor
your
Canadian
taxes,
I'm
sure.
So
here's
the
agenda
prepared
prior
to
the
meeting
we
should
bash
it
briefly.
Chuck
lever
has
two
items
to
present
integrity,
management,
architecture
and
RPC
argument
crediting
those
slides
are
online.
A
Tom
Haines
has
the
open
delegation
versus
delegation
state
IDs.
That
presentation
is
online
and
the
additional
ten
minutes
for
delegation
they're
all
in
one
deck.
So
the
del
sta
tid
thing
as
well
as
offline
files
like
it
sounds
like
they've
Nomex,
slides
were
sent
but
have
not
been
uploaded.
I
will
try
to
do
that.
Offline,
Dave
I
do
have
your
slides
now.
The
magic
with
the
internet
has
delivered
them.
A
A
G
G
G
G
H
H
Front
I
think
this
fits
well
into
our
chart.
So
what
is
this
thing?
What
is
this
thing
all
about?
This
is
a
integrity
measurement
architecture.
This
is
something
that
IBM
cooked
up
a
few
years
back,
they've
been
implemented
and
implementing
it
in
Linux
on
local
file
systems
and,
more
recently,
they've
sort
of
been
thinking
about
what
it
might
take
to
put
it
into
a
remote
file
system.
I
think
they
were
looking
at
SMB,
first,
not
really
thinking
of
NFS,
but
the
nice
earth
came
along
and
said.
A
H
H
H
So
this
is
sort
of
a
rough
idea
of
what
the
use
case
is
what
we
want
to
do
our
first.
Our
primary
use
case
right
now
is
protecting
executables
binary's,
basically
on
mobile
devices,
which
don't
have
anything
new
with
NFS.
But
this
is
just
an
example
you
you
basically
want
to
detect
intrusion
or
even
replacement
of
applications.
For
example,
if
someone
were
to
root
your
phone,
you
basically
want
to
know
whether
the
executables
have
been
replaced
or
not
in
cloud
environments.
H
This
would
be
done
by
the
software
distributor
or
the
or
basically
a
Linux
computer
distributor
like
Red
Hat,
as
they
are
building
a
distribution.
They
would
sign
each
of
these
executables
and
then,
whenever
the
executables
used
on
a
on
an
FS
client,
for
example,
the
H
Mac
would
be
the
signature
be
checked
and
the
H
Mac
would
be
used
to
verify
the
file,
content
and
I.
Think
it's
important
to
note
that
we're
not
using
the
the
verification
doesn't
use
open,
it's
basically,
four
executables
and
executables.
H
When
they're
run
they're,
not
you
don't
do
an
open
on
them.
They're
they're
run
via
exec.
So
that's
why
the
BFS!
That's
why
this
is
all
done
in
the
BFS.
It's
not!
It's
not
exposed
to
applications
in
any
way.
I
may
also,
more
recently,
as
is
allowed
the
verification
of
some
file
attributes
we'll
get
to
those
in
a
minute.
But
there
are
some
complications
there,
but
we
can
verify
so
just
the
TLDR
is.
We
can
verify
the
file
contents
and
a
few
of
the
file
attributes
as
well.
H
H
So
the
document
also
describes
the
protocol
that
the
client
uses
to
retrieve
the
H,
Mac
hashes
and
also
the
protocol
that
the
client
administrative
plan,
for
example,
would
use
to
to
set
the
H
max
and,
as
I
mentioned,
there
are
some
there's
a
small
set
of
file
attributes
that
can
be
verified.
That
set
is
variable,
so
in
other
words
there
there
certain
attributes
that
are
always
going
to
be
verified
in
there.
H
H
Even
in
the
local
file
system
case,
we
recognized
that
performance
of
this
kind
of
verification
is
going
to
be
a
concern
when
you
throw
in
a
roundtrip
with
a
server.
It's
going
to
be
even
worse,
so
we're
gonna
have
to
think
hard
about
ways
of
optimizing:
the
verification
of
hmx
on
large
files,
especially
basically,
we
want
to
have,
for
example,
mechanisms
that
will
allow
us
to
verify
a
part
of
the
file.
H
It
turns
out
that
some
of
the
attributes
that
are
are
they're
talking
about
verifying
on
local
file
systems,
are
extended,
attributes
that
aren't
exposed
via
NFS,
like
smack
security
attributes,
for
example.
So
that's
going
to
be
a
problem.
We're
gonna
have
to
deal
with
that.
Somehow,
probably
today
it's
going
to
be.
We
don't
support
that.
If
there's
a
if
the
file
system
supports
SMAC
attributes
in
there,
they're
actually
part
of
the
set
of
verified
attributes,
then
those
files
can't
be
accessed.
H
H
Then
the
problem
with
bringing
this
into
the
standards
world
this
I'm
an
NFS,
is
that
there
aren't
any
published
standards
that
define
what
what
I
am
a.
Is
there
there's
a
lot
of
material
there's
code,
there's
a
wiki,
everybody
has
a
wiki,
but
there's
no
published
standard.
It's
not
like
a
POSIX
standard,
even
an
existing
one
or
withdrawn
one.
There,
just
isn't
one
so
we're
gonna
have
to
deal
with
that.
H
H
Lots
of
actually
lots
of
operating
systems
have
something
like
this,
but
basically
what
we
do
is
we
chop
up
the
super
user
privilege
in
two
smaller
pieces
like
this
and
they're
assigned
to
an
application?
Just
like
you
set
a
set
user
set
user
ID
bit
on
a
on
a
root
owned
executable,
and
that
gives
basically
all
of
routes,
capabilities
to
that
whenever
that
executable
runs,
we
basically
chop
that
up,
and
so
you
know,
caption
means
that
the
executable
can
can
change
the
ownership
of
files,
but
it
can't
do
anything
else.
H
H
And
the
reason
why
I'm
bringing
this
up
is
because
the
the
set
of
file
capabilities
is
one
of
the
verified
attributes
that
I'm
a
supports.
Nfs
does
not
support
this
right
now,
and
so
this
is
one
of
the
things
we'd
liked
it
to
have
support
for
an
NFS
so
that
we
can
support
with
this.
We
can
protect
it
with
I
ma,
so
these
slides,
basically
last
few
slides
I
can
walk
through
them
the
detail
or
in
just
sort
of
browse
through
them
on
your
own.
H
So
what
I
would
do
is
I'd
probably
write.
Another
document
originally
I
had
folded
both
file
capabilities
and
I
may
into
one,
but
they
have
similar
but
really
separate
issues,
and
so
I
decided.
That
would
be
better
if
we
got
through
the
simpler
one.
First,
which
is
I,
am
a
and
then
we
can
look
at
doing
capabilities,
so
it
would
the
you
know.
The
form
of
that
proposal
would
be
some
very
similar.
It
would
be
a
draft
that
would
describe
an
extension
nfsv4
point
to
and
it
would
cover
some
of
these.
H
So
this
one
does
have
the
final
capabilities
is
based
on
a
POSIX
draft,
but
is
withdrawn
and,
of
course,
the
Linux
implementation
of
file
capabilities
is
heavily
modified
from
that
draft.
It
doesn't
look
like
Solaris
Gate
file
capabilities,
it's
very
similar,
but
the
semantics
of
the
capabilities.
Individual
capabilities
is
different
than
what
Solaris
offers.
So
we
need
to
have
some
way
of
defining
how
a
inter
operation
between
a
Linux
client
that
supports
valid
capabilities
and
a
Solaris
clan
or
some
other
client
that
supports
valid
capabilities.
How
that
would
work
it
turns
out.
H
H
There
isn't
really
that's
one
of
the
issues
that
we
have
to
deal
with.
It's
that's
a
complicated
one
and
that's
one
of
the
reasons
why
I
split
this
one
out
to
a
separate
proposal,
and
it's
not
even
clear
to
me
that
we
can
say
that
user
77
on
client
a
is
the
same
as
user
77
on
client
B
I'm,
just
not
sure
how
that's
gonna
work,
the
user,
the
user
namespaces
don't
look
there.
They
don't
look
like
the
the
user
at
domain.
H
D
H
E
Okay,
so
I
was
just
going
to
say
a
couple
of
things
you
know
you're
talking
about
you
know
is
this
informational
and
things
like
that?
The
the
the
the
thing
I
would
say
is
that
would
encourage
you
all
to
do
the
right
thing
and
make
the
chairs
and
the
area
director
figure
out
what
to
do
with
it,
but
but
doing
the
right
thing
is
never
something
I
were
going
to
speak
against
it
see
if
I'm
understanding
this
correctly.
It's
like
you
have
ima
attributes
that
are
exposed
by
an
offense
before
and
vice
versa.
E
E
Yeah
this
one
here
where
it's
like
you
know,
here's
some
little
X
attribute
that
aren't
exposed
that
are
interesting.
Bye-Bye
here
are
some
things
that
are,
you
know
verified.
It
seems
like
that
this
is.
If,
if
doing
ima
is
a
good
thing,
it
seems
like
this
might
be
a
good
thing.
You
know
a
good
opportunity
to
tie
some
things
together.
You
know
if
this
is
useful
over
here,
but
it's
not
exposed
over
there.
These
do
you
see
what
I'm
saying.
E
H
Can
certainly
address
the
question
to
them.
I
am
Not
sure
I'm
expert
enough
about
what
the
requirements
are
for.
Our
draft
you
know
is
a
is
pointing
to
a
live
URL
a
wiki
page
enough
for
this
or
you
know
what
exactly
do
we
need?
You
have
any
documentation
that
describes.
You
know
what
I
need
to
qualify
the
citation
that
I
do
in
my
document,
dude,
so
wait
so.
E
You
know
our
deal
is
basically
well.
You
know
what
is
the
best
references
you
could
point
to
right,
which,
which
you
know
perfect
world
would
be,
you
know,
would
be
immutable
and
great
and,
and
things
like
that,
but
recognize
you
know
what
you're
talking
about
here,
you're
kind
of
accommodating
something.
That's
not
all
that
nail
down.
Yes,.
E
H
E
D
I
H
H
C
A
H
A
H
A
H
J
H
I
kind
of
brushed
over
this
in
an
earlier
slide
there,
so
the
second
bullet
on
clients,
the
keys
are
stored
in
a
trusted:
computing
module
and
they're
they're,
distributed
via
some
hand-wavy
outer
space
mechanism
so,
for
example,
the
in
a
mobile
device.
The
keys
would
be
installed
by
the
manufacturer,
for
example
on
NFS
clients.
There
were
some
be
some
other
mechanism,
but
there'd
be
some
sort
of
trusted:
computer
module
available
on
clients
to
manage
and
secure
the
key
material.
H
H
A
cloud
provider
might
take
a
golden
master
DVD
from
Red
Hat,
for
example,
and
put
that
insulation
media
on
the
server
and
as
part
of
that
installation
process,
the
hmx
are
computed
there
and
then
exported
to
two
clients.
That's
a
that's
another
use
case
client.
You
know
I,
think
in
in
the
cloud
tenant
use
case.
The
the
clients
aren't
are
not
actually
computing.
These
H
max
they're
they're
only
consumers
of
them.
H
So
about
a
year
ago,
I
think
we'd
start
talking
about
RPC
over
already
made,
then
exactly
what
or
maybe
it's
been
longer
than
that,
and
we
had
a
couple
of
interesting
ideas
that
we
wanted
to
go
with.
There
I
think
what
I'm
going
to
do
with
this
next
presentation
is
solicit
opinions
about
exactly
how
we're
going
to
fix
the
problem
of
credit
management
and
and
I
hope
to
demonstrate
that
it's
a
problem
that
we
do
need
to
solve
in
version
two,
and
we
need
to
figure
out
exactly
if
there
is
a
problem.
H
H
Think,
that's
that's
the
question.
I
want
you
to
hold
in
your
heads
as
I'm,
giving
this
talk
so
I'm,
just
gonna
briefly
talk
about
exactly
what
credits
are
and
how
it
works
in
b1.
Today,
the
transport,
the
RPC
transport
on
our
DMA,
has
a
flow
control
mechanism
in
it,
so
that
the
server
is
not
overrun.
This
mechanism
is
credit-based.
H
H
H
So
that's
how
the
credit
grant
gets
from
from
the
receiving
end
to
the
sending
in
responder
is
the
receiver
so
and
then,
as
part
of
this
protocol,
exactly
one
credit
is
available
as
soon
as
the
connection
is
established,
and
then
that's
that's,
of
course,
before
the
first
reply
has
been
sent.
So
one
credit
is
available
for
the
first
reply.
So
this.
H
So
there
are
some
other
features
of
our
credit
architecture.
I
think
the
two
that
are
well
non
windowing
is
probably
the
most
important
one.
What
that
basically
means
is
our
RPC
of
already
made
one
responders
tell
that
the
requesters,
exactly
how
many
total
RPC
calls
can
be
done.
They
don't
they
don't
tell
how
many
I'm
not
saying
this
right,
it's
kind
of
complicated
Tom.
Do
you
you
help
me
out.
H
So,
to
put
it
in
terms
of
real
numbers
of
the
links
and
if
a
server,
for
example,
sets
up
32
received
buffers,
and
so
the
number
of
credits
that
gives
to
the
two
clients
is
32
all
the
time
it
says.
I
can
take
32
and
that
doesn't
matter
how
many
are
pending,
like
all
32
buffers
might
be
consumed
at
one
moment,
but
the
credit
grant
is
still
32,
so
it's
not
we're
doing,
and
then
adaptive
means
that
the
responders
credit
grant
can
change
during
lifetime
of
connection.
H
In
other
words,
if
the
server
gets
busy,
it
can
reduce
the
credit
grant
assets,
as
I
say,
16,
to
create
some,
but
more
back
pressure
on
clients
non
when
doing
is
important
in
a
subsequent
slide,
so
so
put
a
stick
of
pain
in
that
one.
So
this
mechanism
has
a
number
of
shortcomings.
It's
done
all
right
so
far
for
handling
most
NFS
B
3
B
4
workloads,
but
there
are
some
there's,
some
lack
of
generality
and
some
some
things
that
we
just
can't
do
with
this.
H
Today,
if
there's
no
RPC
transaction
involved
in
a
send
or
receive,
then
we
can't
support
that,
because
a
credit
is
is
connected
to
an
RPC
transaction.
So,
for
example,
if
I
want
to
do
a
control
plane
message,
it's
not
gonna
have
an
RPC
X
ID
associated
with
it.
I
can't
I
can't
really
support
that
with
this
with
this
mechanism,
because
it's
got
to
have
an
RPC
message,
it's
got
to
be
sending
an
RPC
message.
H
Probably
the
biggest
one
is:
it
doesn't
support
unpaired
messages,
the
number
one
most
frequent,
most
common
type
of
unpaired
messages,
retransmission.
So
today,
for
example,
when
the
likes
client
has
to
retransmit,
basically
what
it
does
is
it
send.
It
drops
the
connection
because
that's
it
has
to
reset
the
the
credit
ramp
and
dropping.
The
connection
is
the
only
way
to
do
that
today.
Well,.
A
H
H
Yeah,
yes,
now
we
don't
have
any
use
cases
in
NFS,
but
a
unicast.
A
call
without
a
reply
is
not
supported
the
original
RPC
already.
Maybe
one
had
an
RDM
a
done
procedure.
That
was
a
one-way
transmission
and
that's
not
supported.
There's
no
RPC
message.
Well,
there
is
an
RPC,
it's
part
of
a
purpose
to
transaction,
but
it's
a
one-way
and
then
you
know,
unsolicited
descends
from
responder
to
requester
are
not
supported.
I,
don't
have
a
good
use
case
for
that,
but
well
that's
right!
H
Right!
Yes,
right.
H
I
C
H
H
Tom
mentioned
bi-directional
RPC.
One
of
the
problems
we
had
with
that
is
that
we
had
to
reuse
the
credit
field,
but
as
soon
as
you're
doing
a
call
in
both
directions
that
the
credit
grant
the
credit,
the
use
of
the
credit
field
is
ambiguous.
We
don't
we're
really,
not
sure
whether
you
know
if
there's
no,
if
there's
so
well.
This
is
hard
to
explain
just
trust
me.
This
is
a
problem.
H
It's
okay
until
one
side
wants
to
send
an
error,
an
already
our
D
mayor,
yeah,
that's
the
problem,
and
then
I
mentioned
this
before.
If
one
side
loses
track
of
the
credit
grants,
there's
no
way
to
synchronize
except
I
drop
any
connection,
and
there
really
isn't
any
other
there
there's
an
a
way
for
the
for
one
side
to
go:
oh
gee,
whiz
I
lost.
Can
you
send
me
the
the
grant
again
or
can
you
update
my
grant
or
you
know
it's
just
like
you
just
have
to
drop
the
connection
and
start
from
one.
A
H
Again,
the
things
that
I
just
went
through
all
those
things
can
and
can
cause
a
loss
of
synchronization,
but
yeah
I
agree,
there's
either
their
implementation
bugs
with
that.
That
would
result
in
this
most
frequently
in
in
all
right
generally,
it's
not
a
problem
of
the
protocols
well
design
and
then
here's
another
stretch.
We
don't
have
any
way
of
guarantee
quality
of
service
in
the
sense
that
you
know,
one
side
with
the
other
side
may
want
to
say:
I,
don't
ever
want
to
go
down
to
one.
H
A
H
What
we
want
to
do,
one
of
the
extensions
that
we
wanted
to
allow
not
necessarily
defined
in
the
base
protocol,
but
allow
as
an
extension
to
the
protocol,
is
the
ability,
as
Dave
mentioned,
to
send
an
RPC
that
consists
of
multiple
our
team,
a
sends
multiple
messages
and
without
yeah
with
that,
with
the
current
credit
accounting
that
we
have
in
our
team,
a
RPC
our
team,
a
version
one.
We
cannot
do
that
so
so.
H
H
H
H
Can
be
effective,
yeah
I'm,
I'm,
open
to
your
proposal,
okay
and
then
I'd
written
another
I'd
written
a
draft.
That's
actually
probably
expired
today,
but
it
expired
just
today
that
I'm
planning
to
refresh
but
I
want
to
provide
a
mechanism
for
being
able
for
the
server
to
return
an
arbitrarily
large
RPC
reply.
Basically,
today,
the
clients
have
to
estimate
how
large
the
reply
message
can
be,
and
sometimes
they
get
it
wrong,
because
the
upper
layer
protocols
there
are
certain
operations
in
the
NFS
protocol.
H
A
A
H
So
on
this
slide,
I'm
hoping
to
get
the
conversation
going
by
men,
some
possible
fixes
we
might
consider.
This
is
certainly
not
an
exhaustive
list
of
possible
fixes,
but
one
thing
we're
definitely
going
to
have
to
do
is
instead
of
gating
I
already
may
sends
on
RPC
transactions.
We're
going
to
have
to
do
it
some
other
way
to
allow
multiple
sends
/
/,
RTC
transaction.
H
As
I
said,
the
non
windowing
aspect
of
version-
1
credit
management
was
important.
One
thing
I
think
we
might
want
to
do
is
consider
changing
to
a
windowing
scheme
instead,
in
other
words
through
the
responder,
would
provide
a
dynamic
credit
grant.
Saying
I
have
this
many
buffers
free
right
now
and
it
would
be.
The
total
number
of
the
number
of
pending
are
PCs
I'd.
Rather
than
always,
the
total
number
that
wouldn't
require
next
er
change,
but
I
think
that's
something
we
should
consider
one
thing
I've
seen
other
protocols
do.
H
Is
they
have
a
credit
field
in
their
transport
header
for
each
direction
on
the
connection,
so
one
credit
field
for
client
to
server
or
RPC
transactions
and
one
credit
field
for
server
to
client?
In
other
words,
reverse
direction,
or
we
could
take
our
32-bit
credit
grant
field
and
split
into
two
16-bit.
Yes,
depending
on
you
know
how
creative
we
want
to
get
with
it.
These
in
the
draft.
A
H
H
Yes,
today,
if
you
can,
but
that's
not
necessary,
okay
well
and
then
the
last
bullet
is
the
idea
is
to
add
a
new
proc.
Rt
may
act,
but
it's
only
job
would
be
just
to
akka
an
unpaired
send
and
but
at
all,
it
could
also
be
used
to
convey
the
current
grant.
So
it
could
use
it
to
recover
from
a
situation
where
one
side
that
lost
sync
or
had
sent
a
retransmission
okay,
questions
suggestions.
A
A
A
A
H
A
You
may
want
to
define
think
about
defining
some
sort
of
RPC
RDMA.
You
know
request
space
right
as
a
sequence
number
or
some
sort
of
identifier
in
the
RPC
RDMA
stream,
that
names
each
message
or
that
names
each
set
of
messages
if
you're,
gonna,
fragment
them-
and
you
know,
reassemble
them
on
on
receipt.
A
Words
yeah
I
asked
back
a
credit
grant.
It
sounds
like
you're
gonna
violate
the
ordering
principle
in
the
sense
that
you're
gonna,
intermingle
requests
and
replies
on
a
channel.
For
instance,
are
you
going
to
be
able
to
insert
things
like
a
cancel
that
aren't
logically
part
of
the
data
stream
or
other
control
messages,
and
so
I
think
I?
Think
you're
gonna
define
a
new
sequence
space
at
the
RPC
RDMA
layer?
That
is
not.
A
There
many
protocols
will
simply
use
an
ordering
principle
for
this.
Let's
say
we
are
going
to
start
sending
fragments
and
then
every
message
that
follows
until
you
get
it
done
bit
is
a
member
of
this
fragment
sequence.
But
you
know
you
might
be
able
to
insert
something
in
that
sequence
now
and
that
breaks
the
ordering
well.
A
Layer
mess
right,
you
could
make
that
you
could
make
that
requirement,
but
that
you're
gonna
explicitly
add
that
processing
requirement
to
our
PC
RDMA
that
wasn't
there
today
isn't
there
to
do
so.
I
I
think
it's
an
opportunity
to
think
through
how
you're
gonna
name
operations
in
RPC
RDMA
space
right
now.
They
simply
inherit
the
name
of
the
X
ID
of
the
RPC
operation
that
they're
carrying
and
that's
why
they
look
the
way
they
are
that's.
Why.
H
H
H
A
F
I
A
H
A
H
My
personal
feeling
is
that
we
need
to
address
all
this
and
be
to
one
of
the
questions
I
came
into
this
sock
with
was.
This
is
something
we
think
is
something
we
need
to
fix
and
be
to
do.
We
agree
that
this
is
something
v2s
needs
to
address.
I,
think
I'm,
seeing
nodding
so
I
would
like
to
I,
would
whatever
happens.
I
think
I
would
like
to
address
it
in
that
draft.
So,
okay,
no,
we
have
to
move
on
so
on
yeah.
H
D
Okay,
I
had
a
problem
at
the
airport,
because
I
was
too
tall.
The
automated
face
tracker,
oh
yeah,
I,
kept
on
going
down
like
this
I
got
upset,
so
delegation
of
state
IDs,
well,
I
thought
I'd
do
with
these
slides
as
I
thought.
I
would
go
over
the
problem
and
not
go
over
the
the
document.
So
I
came
up
with
a
standard
format.
I
was
bored
on
the
plane.
The
the
first
problem
we
talked
about
is
offline
files
and
the
use
case
that
we
actually
have
is.
We
were
in
testing
and
development,
and
we
we.
D
Browser
looks
at
like
I
think
the
first
64k
of
the
file
and
says
this
tries
to
give
a
preview
of
the
file
in
the
browser
when
you
hover
over
it,
and
we
looked
at
the
sequence
of
opps
and
we
saw
a
an
open
and
we
said:
why
are
we
sending
yell?
When
will
the
opens
being
sent
because
the
file
browser
wants
to
open
it
and
that
led
to
a
read
request
that
yes,
the
datastore-
and
you
know
we
just
don't
want
that.
D
So
we
looked
at
what
SMB
was
doing
and
it
was
looking
at
the
offline
bit
and
saying
if
the
file
is
offline,
don't
download
it,
don't
open
it
for
this
file
browser
and
we're
looking
at
the
cost.
The
cost
is
dollars
even
investing
in
QA
testing.
We
have
to
get
a
copy
from
the
remote
store
and
most
likely
we're
just
going
to
either
throw
that
copy
away,
or
we
turn
it
back
to
the
object
store,
which
is
more
cost
I
go
fast
by
the
way
slow
me
down.
D
If
you
need
to
ask
questions,
yeah,
well,
I'm
good
I'm,
about
through
a
third
of
my
slides
and
take
five
minutes.
That's
all
right!
Yeah!
The
solution
is,
we
want
to
introduce
a
new
attribute
called
the
offline
bit
and
that's
going
to
simply
when
the
client
does
a
get
adder,
the
initial
sequence.
It's
going
to
see
it's
going
to
ask
to
say:
do
you
support
the
off?
Do
you
have
the
offline
bit
if
it
does
have
the
offline
that
we
send
it
back?
D
The
client
will
not
open
the
file,
and
so
you
know:
here's
where
I
ID
v8
from
the
slides
I
was
thinking
on
the
introduction.
All
of
all
of
the
work
I'm
showing
is
driven
by
the
fact
that
we
have
someone
in
QA
or
we
have
some
director
who'll,
come
to
us
and
say
why
do
you
keep
on
sending
get
X
right
and
so
we're
trying
to
reduce,
get
adders
we're
trying
to
reduce?
D
A
D
Yes,
exactly
and
then
you
know
another
one
we
did
was
we
used
to
have
an
open
and
a
layout
get
being
the
same
compound
and
we
broke
occasions
where
we'll
break
that,
because
we
want
the
the
layout
get
is
expensive.
We
only
want
the
client
to
do
that
open.
You
know
when
they
explicitly
have
to
read
the
file
proxying
of
times
so
I'm
another
one
we
saw
was
we
are
our
CEO
has
a
simple
use
case.
D
He's
got
40,000
files
from
presentations
from
his
past
companies
to
now
he
unties
them
across
the
network
and
he
uses
that
as
a
quick
performance
goal.
Alright,
it's
not
very
scientific.
He
has
the
new
presentation,
things
change
out,
but
it's
the
very
simple
right
workload
and
he
uses
it
to
break
break
me
all
the
time.
So.
D
We
we
have
another
besides
the
simple
metadata
server.
We
actually
have
another
gateway
for
d3
and
for
SMB,
and
it
allows
our
our
storage
device
to
only
speak
nfsv4
to
and
when
we
want
to
allow
access
to
legacy
clients.
We
have
data
portal
that
speaks
and
if
sp3
and
it
speaks
that
SMB
and
so
as
the
client
connects
it's
translated
to.
We
have
a
file
cache
it
that
keeps
the
v4
file
open
and
allows
the
client
to
connect
through
and
one
of
the
things
we
found.
D
What
was
happening
is
that
the
data
portal
would
essentially
expand
to
get
out
a
request
from
the
client
and
spam
storage
device,
and
we
were
wondering
why
this
was
occurring
and
we
were
looking
at
the
the
get
adders
and
we
were
thinking
we'll
wait.
Why
are
we
sending
get
at
us
we're
sending
NFS
v3
rights?
They
have
WCC
that
should
be
supplying
information
to
the
to
the
proxy
cache
and
I
spoke
to
the
Linux
client
in
Finland
reason.
Well,
we
can't
trust
that
I
said
well.
Why
can't
you
trust
that?
D
He
goes
well
because
the
DES
is
not
authoritative
on.
D
Is
not
the
one
that's
authoritative
on
the
time,
and
so
and
we
looked
at
the
test.
The
internal
test
I
just
described
and
it
was
40k
files
and
we
saw
72k
get
a
ders
right
and
we
want
to
reduce
those
and
so
I
said.
Well.
What
do
we
have
to
do
to
make
the
DSO
thorat
ativ
on
the
right?
We
cache
consistency
and
the
reply
was
we
had
to
delegate
not
only
the
size
but
the
proxying
of
the
times?
D
D
Well,
you
would
think
it
does.
We
don't
have
that
social
clustered
relationship
all
right,
so
the
things
we
had
to
put
in
place
is
we
had
to.
D
D
E
A
D
They
do,
and
you
know
when
I
was
doing
the
slides
yesterday,
that
came
to
me
with
we
do
I,
don't
have
it
inside
deck.
I
haven't
to
require
I
said
to
Mike
yesterday
in
the
email.
So
what
we
have
to
do
is
the
cluster
has
to
mean
that
the
metadata
server
has
to
maintain
a
view
of
what
each
data
store
has
the.
D
Key
give
me
the
size
and
give
me
a
time
at
that
point.
The
metadata
server.
A
J
D
So
when
when,
when
we
do
such
a
proxy,
then
then
the
the
the
metadata
server
doesn't
bother
asking
the
client.
Will
the
metadata
server
assumes
the
client
that
owns
it?
It's
not
going
to
ask
because
it
knows
the
information
and
it's
finally,
when
what
so
we
have
to
allow
callback
so
that
the
metadata
server
can
get
the
information
for
another
client.
D
When
the
client
that
owns
the
delegation
is
done
with
the
delegation,
it
has
to
do
a
set
adder
to
set
that
information
back
and
by
the
way
it
has
to
have
a
new
attribute
to
do
that
so
that
it
can
say
this
is
the
field
on
the
authoritative
floor
and
I'm,
giving
the
answer
versus
you're
trying
to
do
an
explicit
setting
of
those
attribute
fields,
as
you
might
do
with
ATAR,
and
on
the
test
workload.
We
saw
three
dead
adders
instead
of
72,000,
as
you
can
imagine,
that
was
a
significant
savings.
D
D
D
Well,
if
you
returned
most
of
the
delegation
states,
you
have
to
maintain
an
extra
state
which
can
be
costly
when
you
have
a
million
files
open.
The
client
also
has
to
send
a
close
too
closely
to
get
rid
of
the
open
state
ID,
which
also
means
you're,
going
to
see
another
get
a
derp
and
get
others
evil
small
costs,
but
they
add
up.
D
So
the
solution
is
that
when
the
client
asks
for
an
open,
it
can
set
a
flag
saying
I
either
want
the
open
or
the
Delic,
but
not
both.
The
MDS
will
try
to
return
only
one.
It
might
return
both
because
it
might
be
an
old
MDS
and
the
other
complication
is
that
the
MDS
has
to
determine
the
correct
state.
D
D
Those
were
the
three
items
we've
got
in
the
draft
version.
Zero
was
published,
I
have
three
reviews
I'm
going
in
reverse
order,
so
I've
gotten
Mike's
review
done
I'm
in
the
middle
of
chalks
than
I
have
Dave's
and
I
want
the
next
draft
version
to
be
an
official
working
group
item,
questions
comments.
I
D
Know
that
my
reply
is
there
they're
pretty
much
90%
of
the
document
is
boilerplate
and
I
struggle
with
you
know.
So,
when
a
Chuck's
comments
was
your
abstract
should
be
the
last
line
and
I'm
that's
even
too
terse
for
me
and
I'm,
a
teacher,
so
I
want
to
keep
them
as
one
because
it's
there
they
all
are
related
and
they
deal
with
open
and
delegation.
Stay
tight.
A
Procedurally,
I
think
it's
okay
for
you
to
choose.
However,
many
drafts
you
feel
is
appropriate
if
they're
related
in
your
mind,
that's
okay,
yeah,
they
are
working.
Group
may
still
choose
to
reject
or
pick
apart.
You
know
these
things,
but
that's
part
of
the
course
of
the
working
group.
Yes,
work
so
either
is
acceptable.
I
think
that's
a
personal
opinion.
A
D
A
G
E
A
A
A
I
Okay,
so
I'm
going
to
talking
about
some
stuff,
that's
farther
longer
than
the
other
stuff,
so
we're
having
to
wrap
up
a
few
things,
and
this
is
what
I'm
going
to
talk
about
so
I'm
talking
about
number.
There
are
three
drafts
involved
for
the
that
Bob
Moses,
both
the
multi
server
namespace
features
of
anapests
before
that's
zero
and
one
sort
of
to
this
work.
In
theory,.
I
Okay
so
said
we
all
right
that
do
you,
click
no
I,
didn't
I
swear
it
all
right.
So
he
had
this
bug.
Servers
name
we've
been
plagued
with
problems.
You
know
I
was
I.
Did
you
know,
did
this
these
chapters
in
in
all
these
all
these
RFC's
and
somehow
I
screwed
up
all
of
them?
Sorry
about
that
anyway,
work
has
been
gone
to
address.
I
These
first
of
all
was
RFC
7931,
which
became
to
propose
standard
in
2016
and
the
three
that
I'm
talking
about
now
we're
working
on
finishing
up,
which
is
migration
issues,
the
update
friend
bees
from
for
minor
version
zero
and
the
update
from
minor
version,
one
and
I
think
all
those
are
coming
along
pretty
well.
So
let's
go
in
the
next
one.
I
The
areas
that
provide
for
is
trunk
and
detection,
all
right,
which
that
is,
if
you
have
two
IP
address,
you
want
to
make
sure
you
want
to
turn
whether
connected
to
the
same
server
and
that
has
so
far
you
RFC,
7931
and
RFC
50cc
one
been
dealt
with.
Then
we
have
in
addition
to
trunk
and
protection.
We
need
trunking
discovery.
That
is
you
given
that
you're
connected
to
one.
You
have
one
connection
to
the
server.
How
do
you
find
the
other
ones?
I
Trunk
induction
says?
Well,
if
you
had
one
you'd
be
able
to
sail,
seaville
is
a
real
one,
but
trunk
and
discovery
is
something
else,
and
we
need
that
for
both
NFC
4.0
and
for
B
4.1.
We
also
need
transparent
stake
migration,
because
when
you
have
a
filesystem
migrate
from
one
server
to
another,
you
have
to
have
the
ability
to
trend
easily.
I
Have
the
client
continue
to
access
the
files
that
he
was
accessing
them
without
the
possibility
than
the
losing
state
or
being
opened
by
someone
else,
so
that
has
been
defined
for
reported
out,
but
his
need
for
before
that
one,
and
also
all
the
reward.
We've
only
now
become
aware
of
it.
We
have
to
deal
with
the
possibility
of
multiple
connection
types
Dave.
I
I
We
had
that
Sweden
skidded
7931.
You
know
that
was
we
the
same,
that
same
issue
and
I
think
we
had
to
follow
through
all
right
any
way
we
can
all
right
we'll
go
on
to
the
next
slide
and
we'll
discuss
all
right
first,
we'll
discuss.
These
are
the
various
documents
and
standards
Soviet.
So
we
said
in
RFC
we
35
30.
We
start
out
with
no
support
for
trucking
trunking
in
corn,
dog
RFC,
35
30
is
a
problem.
It's
not
a
feature
and
is
a
problem.
I
It's
Warren,
sir
Darkly
about
what
might
happen
if
you
have
most
of
multiple
connections.
That
goes
to
some
effort
to
prevent
that
from
being
determined
anyway,
RFC
3261
did
provide
trunking
detection,
but
for
some
reason
we
thought
we
didn't
think
about
the
problem
of
trunking
discovery
and
seven
artists,
RFC
75
30.
That
was
an
opportunity.
We
have
to
address
trucking,
but
we
do
it
then,
and
we
finally
did
it
in
RFC
7931.
I
I
All
right
now,
draft
IFT
fnf
is
before
migration
issues
has
been
gone
for
a
very
long
time.
It's
been
like
three
years
yeah
at
least
all
right,
but
it's
somebody
making
for
southern
making
progress
and
I
think
it's
getting
fairly
near
and
dresses
a
lot
of
stuff,
there's
a
migration,
shrunken
detection
and
discovery
and
multiple
connection
types,
and
it
deals
with
that.
The
decision
was
to
do
like
in
this
case.
We
didn't
want
to
have
separate
documents
for
reported,
oh
and
reported
one,
because
the
problems
are
so
similar
and
solutions
are
mostly
similar.
I
J
I
B14
I
thought
that
had
has
had
a
lot
of
review
it
disguised
trunking
discovery,
transparent,
state
migration.
Now
the
discussion
of
transparent
migration
sort
of
describes
what
has
been
done
in
7931
and
the
one
for
before
dot
one
describes
what
will
be
done
so
they're
different,
it's
in
pretty
good
chip
shape.
We
have
no
pending
issues
and
I
recently
published
15,
which
includes
the
handling
of
multiple
connection
types
and
also
another
thing
which
people
should
look
at.
Is
the
discussion
of
possible
extensions
to
be
4.2
I
think
originally,
there
was
some
discussion.
I
I
The
original
target
date
multi-channel
yep,
the
original
target
date
has
gone,
has
gone
by
I
was
really
supposed
to
done
by
by
June,
but
anyway,
I
think
I
sent
the
working
group
a
copy
of
my
mails
to
mail
to
the
Spencer's
and
I'm
thinking
that
we
should
get
it's
done
by
it
by
August.
You
start
15
the
current
or
is
that
the
next
upcoming
version.
A
A
I
Right
so
we
do
want
to
get
to
Google
welc
soon,
okay,
material
at
14.
The
review
should
already
have
occurred
and
if
it
hasn't,
let's
see
that
gets
done.
Changes
15
have
been
out
for
a
month
and
this
still
might
need
some
further
review.
Now.
I
expect
that
I
expect
that
to
be
16
now,
16
will
have
materia
about
the
RC
1
FS
issue,
which
is
discussed
in
the
next
one.
That
was
brought
up
by
Rick
Macklin
and
don't
know
exactly
what
to
do
about
it.
But
I've
been
working
on
addressing
it.
I
I
have
a
version
of
16
that
I
could
review,
but
thanks
the
guy
on
the
mail
from
Rick
said
well
gee.
If
I
know
that
that
VMware
addressed
this
and
led
to
think
maybe
I
wouldn't
brought
this
up.
I
still
think
it
does
have
to
be
brought
up,
but
I
think
the
burner
has
to
discuss
that,
but
it
will
be
a
16
out
pretty
soon
and
so
I
I
won't
want
comments
on
15
by
within
about
three
weeks
from
now
and
then
based
on
the
comments.
I
I
Vmware
does
reclaim
complete
with
our
C
1
FS
set
to
true,
although
Falls
is
what's
supposed
to
be
and
Rick
points
out
that
the
treatment
is
not
as
explicit
as
it
should
be
about
what
the
purpose
of
reclaimed
complete
with
when
FS
set
to
true
is,
and
so
one
one
thing
that
might
do
we
might
do
is
clarify
that
and
may
servers
work
with
current
being
where
the
client
behavior
and
I'd
like
to.
If
we
do
fix
the
spec
also
allow
interoperability
with
the
existing
clients.
I
So
anyway,
I've
been
dancing
around
that
and
I
think
that's
not
an
issue
4-16
of
migration
issues,
because
my
des
60
of
migration
issues
says
only
that
we
need
to
address
this
later.
I'll
talk
about
MV,
one
where
we're,
which
is
much
I'm
working.
It's
still
working
we're
also
working
on
anyway.
My
I
think
migration
issues
will
probably
meet
I
say
here
will
meet,
but
I
I
said
working
group
hasn't
designed
that,
but
we
have
to
decide
what,
although
I'm
doing
migration
issues
about
that.
Rather
than
want
to
address
that
that
issue,
that's
going.
I
Alright
now,
unlike
the
others,
other
specs,
the
goal
for
this,
the
milestone
goal
for
this
is
get
to
working
group
last
called
rather
than
final
vacuuming,
because
we
don't
know
for
sure
whether
they're
gonna
produce
the
final
thing.
We
could
produced
an
information
document
which
we
could
submit
for
publication,
but
it
isn't
clear
it's
worth
doing
that
and
the
working
group
needs
to
decide
and
I've
I've
gone
both
ways
on
this.
The
pros
are:
this
explains
the
over
reasons
for
these
changes
in
a
way
that's
RFC
7931
and
the
immaterial
individual.
I
I
That's
the
we
have
to
make
a
decision
about
that
at
some
point
and
I'm
not
sure
exactly
how
they'll
do
that
and
that
you're,
rather
that's
the
working
group
to
decide
or
whether
the
the
authors
and
an
editor
will
decide,
but
we
have
to
make
a
decision
about
that
sometime
and
I.
Think
after
we
should
probably
decide
about
what
will
go
forward,
that
after
wgl
see
yep.
F
David
brock
been
involved
in
a
related
situation,
another
working
group
that
I
don't
want
to
talk
about,
but
let
me
see
if
I
can
extract
some
useful
of
us.
I
think
the
crucial
question
is
almost
down
the
bottom
of
slide.
Does
this?
Does
the
contents
of
this
draft
so
do
the
Conesus
draft
have
archival
value
over
and
above
the
other
RFC's
published?
Will
they
help
someone
who
is
trying
to
implement
the
RFC
7931,
and
it
looks
like
an
RFC
to
be
on
trunking,
want
to
read
this
doc
to
figure
out
how
to
get
implementation
right?
F
I
F
Think
that's
the
question
to
the
working
group.
Will
this
doc
have
archival
value
to
implementers
in
the
future?
Once
the
working
group
has
a
position
on
that,
then
the
higher
level
sausage-making
can
move
from
there.
Spencer
is
familiar
with
the
situation
that
I'm
bleep
Lehrer
furring
to
and
don't
want
to,
discuss
and
we'll
understand
the
sausage-making
reference
all
right.
K
A
F
Make
the
decision-
let's
back
off
from
let's
back
off
from
the
decision,
I,
believe
that
there
are
two
to
sit
there
at
least
two
decisions
here
decision
one
is:
is
the
working
group
needs
to
come
to
rough
consensus
on
archival
value
or
lack
thereof
in
this
talk
that
it's
absolutely
working
decision
that
is
owned
by
the
people
in
this
room
online
and
on
the
mailing
list?
Is
this
document
useful
to
publish?
Does
it
have
value
to
future
implementers
and
I'm
just
using
implementers?
It
might
be
broader,
but
that
decision
is
organization.
F
Once
written
group
has
a
rough
consensus
decision
on
that,
then
the
high-level
sausage-making
starts
to
figure
out
whether
that
decision
leads
to
publications
of
an
art
as
an
RFC
or
not.
But
let's
get
the
decisions
in
the
right
order,
and
the
working
group
should
focus
on
the
technical
question
of
archival
value
of
this
document.
Okay,
perfect.
F
C
I
I
I
I
H
I
A
H
I
I
Right
now,
there's
a
corresponding
document,
which
is
Lunas
quest
far
along
its
that
addresses
the
report
that
one
needs
that
has
two
parallel
rather
than
just
depending
on
7931.
It
has
two
parallel
that
work,
and
actually
there
was
a
lot
of
things
about
how
you
deal
with
PMF
as
a
few
other
things.
Anyway,
it
was
like
it
was
that
document
is
we
got
and
it's
it's
it's
longer
it's
about
it's
about
60
or
70
pages.
I
Anyway,
it
adds
trunking
discovery,
just
as
the
versus
ear
does
shrunken
detection
was
already
present
in
fifty
sixty
one,
it's
transparent
state
migration
and
the
own
one,
which
has
been
out
recently
as
further.
It
hasn't
been
out
that
long
isn't
further
material
on
multiple
connection
types.
Alright,
next
slide.
I
I
Maybe
we
need
to
let
that
sit
and
proton,
given
that
that
one
has
a
longer
target
date
which
at
blue,
which
is
March
2019
this
time
for
product
implementations
to
be
done,
and
if
people
do
prototypes
and
find
problems,
then
now
is
the
time
to
report
that
views
gonna
take
place
on
the
working
group.
May
Lulu,
listen
I,
urge
people
to
continue
to
look
at
the
documents
and
and
tell
me
if
I
didn't
tell
us
about
issues
and
if
people
think
a
conference
call
will
be
helpful,
you
can
schedule
that.
I
All
right
now,
the
target
for
this
document
is,
is
final
document
submission
by
March
2019,
which
implies
that
you
for
that
to
make
to
make
that
prep
to
have
to
have
working
with
last
call
by
January,
see
everyone
is
out
ready
to
be
reviewed
and
it
could
be
the
WGAL
C
candidate,
but
there
might
be
a
need
for
wo2
if
we
decide
that
there
are
some
issues
with
RCA
one
FS
and
that
will
be
an
they'll,
be
that
discussion
will
follow.
The
discussion.
I
I
think
I
really
want
to
hear
about
what
McGrath
Rick
Mac,
who
thinks
about
what
we
need
to
include
that,
but
I've
done
the
work
and
I
could
have
an
IO
to
out.
If
we
decide
that
we
that
needs
to
be
done
and
if
we
ever
need,
we
need
version
B
on
o2
and
would
have
to
just
today,
but
I,
don't
think
we
will
have
to
I
think
we
will
get
this
out
and
done
by
March
2000.
A
A
H
I
She
wasn't
say
that
he
was
ignoring.
He
was
basically
looking
at
it
saying,
oh
because
there
is
no
could
be
no
migration
here.
I
can
just
ignore
this,
which
is
slightly
different.
Okay
and
I.
Think
okay,
zero
draft
zero
to
it
that
I'm
working
on
I
sort
of
address
it
in
that
light.
Okay,
all
right,
I
think
that's
it
for
that.
For
that
slide,.
I
A
I
Do
that
yes,
I
did
I
didn't
want
to
write
very
small
anyway,
so
my
group
we've
been
talking
about
a
lot
of
those
in
the
previous
thing,
migration
issues,
as
I
said,
it's
an
information
document
probably
and
wgl
C
is
the
goal
and
that's
expected
by
August,
I
hope
and
nvme.
For
PMF
s
is
not
very
far
along.
You
know,
there's
there's
another
slide
where
all
talk
I'll
go
through
this
this
table
and
then
we'll
talk
about
the
problem
about
the
problem.
I
Children
all
right
now
before
dunno
trunk
and
discovery
chuck,
is
doing
that
he
I'm
odd
car.
The
duke
oh,
he's
the
editor,
and
we
see
that
seems
to
on
track
or
better.
Now
there
turns
out
the
other
document
before
to
one
document.
We
have
this
part
of
two
goals
and
we
retain
them
as
two
goals:
they're,
both
on
track
and
the
movies
will
be
addressed
by
one
document
and
we're
hoping
probably
that
will
be
out
five
March
2019.
I
H
H
I
A
H
A
H
A
Let's
talk
about
it
because
I'm
not
sure
what
your
original
concern
might
have
been
I,
don't
think
I
had
one.
Although
I
was
concerned
that
the
private
data
was
defining
a
blob
of
network
transmitted
data
that
was
not
sufficiently
clarified
with
respect
to
its
requirement.
The
RFC
already
made
protocol
right.
H
A
I
am
curious.
What
they
are
I
haven't
looked
at
this
document.
Sometimes
so
I
should
refresh
my
thinking
on
it,
but
while
we're
here,
let's
talk
okay,.
I
A
I
Okay
sure
now
there's
a
lot
of
a
lot
of
interest
at
one
time
in
the
item,
a
layout
for
through
PN
FS,
and
that's
also.
We
don't
know
where
that
is
the
target
is
target,
is,
is
September
2019
and
it
doesn't
I'll
have
some
slides
about
that.
That's
also
a
problem
child
now
chucks
just
talk
about
some
stuff
for
our
PCOR
in
the
version
and
that
has
a
target
date
for
final
submission
of
December.
2019
I
think
it's
on
track,
but
chunks
brought
out
some
issues.
A
I
I
I
All
right
also,
we
have
the
ability
to
add
milestones
and
I.
Think
we've
been
working
with
a
a
two
year
window,
so
a
two
year
window
from
now
is
August.
2020
are
the
documents
that
that
potentially
have
milestones
and
some
of
the
people
here
or
listening
might
have
these
documents.
We
need
an
owner,
some
sort
of
reasonable
target
date.
You
have
some
sort
of
confidence
and
I.
Think
Spencer's
has
been
cleared,
that
he's
not
gonna
ask
for
your
signature
and
blood
or
anything,
but
there
has
to
be
working
group
in
interest.
I
So
some
things
that
we
thought
about
his
integrity
management
measurement
Chuck
is
presented
about
other
possible
descendants
of
set
sec,
ylabel
extensions
or
descendants,
or
a
singular,
singular
or
plural
of
Tom's
Dell
state
ID.
Also
another
possibilities
that
I
thought
about
is
flexible
files
v2.
If,
if
you
have
interested
in
that
in
pursuing
that.
D
Yeah,
actually
I
do
I
and
I
I
have
a
problem
with
the
Flex
false
v2,
in
the
sense
that
I
have
one
small
change
I'd
like
to
get
in,
but
I
think
it's
just
heavy-handed
the
way
we
hit.
We
have
to
rev
the
base
to
class
to
have
a
new
layout
type
in
order
to
to
do
a
change.
I
can't
think
of
another
way
to
your
minor
version
on
a
layout
type,
I.
I
I
D
I
A
D
I
Yeah,
alright,
let's
go
on
now
nvme
for
PMF
s,
so
the
current
status
there
is
the
ideas
expired
and
we
have
seen
no
progress
beyond
what
was
discussed
in
ayodhya
tip
2
tonight
in
the
ietf
99.
The
current
tired
tarde
target
date
has
gone
by
now
in
considering
progress.
Well,
I,
think
Chuck,
isn't
one
who's
actually
talked
to
Christophe
and
crystal
does
say,
he's
interested
in
working
this,
but
I
think
Chuck
tried
to
get
a
data
of
Christophe
was
unable
to
make
Chuck
would
tell
me
Rick.
H
I
So,
what's
neat
is
well
I.
Think
you
David
you.
You
had
discussion
with
Christophe
about
what
wasn't,
even
in
this
document,
that
the
ITA,
@I,
f,
99
and
I.
Think
Chuck's.
Memory
of
this
and
mine
are
somewhat
different.
I
thought
think
you
just
you
decided
that
a
fair
amount
of
work
was
required
and
I
think
Chuck
remembered
that
it
was
more
smaller
and
he
was
sort
of
wondering
why
Christophe
didn't
do
it,
given
what
they
thought.
Only
a
small
amount
was
needed.
Don't
we
were
waiting
for
a
citation
or.
A
H
I
I
I
A
A
H
H
C
I
I
I
All
right
there
you
go
so
well
other
things
we
might
do
is
well.
Maybe
we
need
a
more
limited
document.
Maybe
they
I'm
right
about
what
David
suggested,
and
maybe
we
want
something.
That's
more
like
an
informational
document
that
just
sort
of
gives
people
some
some
are
limited
document,
there's
not
maybe
not
Stan
distract
it
just
give
them
their
instruction
to
how
you
might
use
this.
Maybe
it's
not.
I
H
I
A
I
Gets
out
and
pushes
that
be
great?
Yes,
okay,
yes,
okay!
H
I
Think
we
now
need
to
consider
how
realistic
that
they
did
is,
or
even
was,
and
given
that
Christophe
has
some
work,
that,
on
the
on
the
on
the
nvme
lay
out
that
he's
not
gay,
there's
a
question
of
well.
How
much
of
the
time
is?
Gonna
have
do
this
so
anyway.
Well,
I
think
that
we're
perplexed
on
this
one
as
well,
so.
A
A
Is
a
look:
this
is
a
big
project,
it's
a
question
of
who's,
doing
the
work
at
this
point
whether
we
have
whether
we
have
any
confidence
in
the
target
date
right
right.
We
have
a
known
issue.
Somebody
needs
to
dig
down
on
the
issue
and
and
and
express
it
in
a
way
that
the
author's
can
document
or
correct
the
protocol
or
whatever,
okay.
J
H
A
H
H
H
A
I
A
H
H
A
I
I
Now,
right,
I
guess
is
one
more
slide.
Well,
you
know
this.
We
raised
this
with
the
other
conditional
authors.
Maybe
Christos
doesn't
want
want
this,
but
maybe
that's
not.
Maybe
that
isn't
despised.
So
does
the
working
group
ahead?
This
Christophe
has
veto
power
of
this
ken's
be
done
by
someone
else.
If
there
is
someone
else
to
do
wants
to
do
it,
I
think.
H
F
Personal
draft,
okay,
which
case
what
probably
the
what
what
Chuck
described
I
was
going
to
say,
is
that
if
you
have
a
working
draft
which
progress
is
not
being
made,
it
is
possible
to
add
to
or
or
replace,
the
r-13
but
the
SIL
initial
draft.
Then
then,
what
would
need
to
happen
to
somebody
write
another,
an
initial
draft
and
they
can
take
as
much
content.
So
you
know
from
the
existing
where
as
they
like
with
with
with
with
civil
acknowledgement.
F
E
I
Alright,
they
are
I,
guess
we
have
to
that
that
discussion,
because
well
this
is
important
people
and
I
hope
someone
does
does
is
interested
in
working
on
this,
but
I
don't
know
who
that
might
be.
So
that's
we
are
that's
why
this
is
another
problem.
Child
project,
okay,
I,
think
that's
into
this
discussion.