►
From YouTube: NFSV4 WG Interim Meeting, 2020-04-22
Description
NFSV4 WG Interim Meeting, 2020-04-22
B
A
The
target
the
current
target
day
is
August
2020
right
now
we
don't
have
a
working
group
document.
The
target
date
has
to
be
considered
tentative.
We
may
need
to
discuss
possible
new
target
target,
we'll
be
hearing
about
that
that
that
work
from
Sauron
on
the
29th
all
right.
The
other
thing
that
we'll
be
hearing
about
today
is
our
PCR
DMA
version
2.
When
the
$2
so
see
eight
documents,
that's
targeted
at
December
21.
That
seems
to
be
on
track
I'm,
assuming
the
current
I'm.
A
One
of
those
internationalisation
that
that's
to
be
a
document
that
deals
with
internationalization
for
all
event
at
64
at
first
amenity,
submitted
an
ID
on
the
14th
of
December
and
submitted
the
oh
one
recently
and
will
will
have
to
work
toward
promoting
that
to
be
a
working
group
document
and
I
think
we
should
decide
on
the
target
date
for
that
soon,
but
I
really
can't
figure
out
what
we
need
to
in
terms
of
review.
I'll
talk
about
that
later.
A
A
And
finally,
we
have
RFC
56
61
bits
and
doesn't
know
I'm
before
starting
work
on
that
I
have
to
work
until
I
have
RC
56,
61
Cesc.
We
use
a
base
and
I
don't
know
when
that
I
figure
that
up
that's
not
happening
now
might
be
a
month
and
we'll
just
see
what
it
is
and
once
that's
out
we'll
just
discuss
I'll
decide
in
the
target
date,
and
it
would
speak
to
Magnus
about
that.
So
that's
the
end
of
that.
So
now
we'll
move
on
the
next
person
all
right.
A
A
A
C
A
C
C
C
C
Oh
second,
what
I'm
trying
to
show
here
is
the
sequence
of
events
where
we
open
the
file.
We
get
the
device
info.
We
write
the
file,
we
return
the
layout
and
when
we
return
the
layout
II,
the
MDS
and
green
has
to
go
to
the
DES
and
said
I
hate.
What
are
the
current
set
of
attributes
because
the
the
MDS
has
no
notion
of
whether
or
not
the
file
has
been
modified?
C
Remember
the
the
only
control
protocol
for
the
back
end
is
NFS
v3,
so
it
does.
Does
this
operation
in
what
we
contend
is
this
operation
is
expensive
because
the
client
already
has
from
the
right
gotten
this
information
from
it.
Sweet
cash
consistency
model
and
it
could
send
it
to
the
DES
we
advanced.
Please.
A
C
C
C
Next
slide,
please
sure
we
looked
at
several
operations,
a
layout
return
modification
that
meant
we
had
to
spin
up
a
new
version
of
the
Flex
files
type
the
layout
commit
the
layout
commit
actually
has
strong,
cache
consistency,
not
weak.
It
has
additional
semantics
that
we
don't
want.
So
you
know.
Basically,
we
looked
at
RFC
1813
yanked
out
the
WCC
and
presented.
F
G
C
So
this
catches
us
up
with
what
we
had
at
105.
The
first
version
had
everything
but
the
layout
we
cache
consistency.
We
agreed
to
make
it
a
working
group
item
and
I
never
finished
off
the
review
items:
okay,
I've
gotten,
since
this
slide
was
written,
originally
I've
gotten
an
additional
review
from
David
and
I
haven't
looked
at
it
because
I'm
I'm
well
next
slide
and
I'll
try
and
explain
it.
There.
C
C
So
this
goes
back
to
the
when
we
delegate
the
end
time
and
the
C
time
or
the
end
time
in
the
a
time
to
the
client
that
has
the
delegation
and
it
caches
locally
those
times
hands
them
out
to
the
application,
and
what
happens
is
when
we
return
those
times
back
to
EMDs
time.
Skew
is
really
kind
of
in
your
face.
C
You
have
to
determine
whether
the
time
given
back
by
the
client,
how
does
it
compare
to
your
clock
and
regardless
of
how
it
compares
to
your
clock,
you're,
basically
bounded
by
the
fact
that
it
can't
be
in
the
future
and
you're
most
likely
gonna
say
you
know
what
I'm
just
going
to
use
the
now
time.
That's
on
the
onion
D
s,
so
you
you
end
up
touching
the
p.m.
C
time
for
the
file,
and
this
is
problematic
in
the
sense,
if
you
have
a
code
like
F
test
or
XFS
tests,
or
any
of
these
utilities
that
try
to
do
pasta,
compliance
once
the
the
really
simple
ones,
a
they
do
a
clock
to
create
a
file
they
they
make
some
test.
That's
gonna
do
something
for
positive
compliance
and
then
they
sleep
for
a
second
and
then
they
take
a
stat
and
they
assert
whether
or
not
something's
changed
well
with
delegation.
Caching,
it
doesn't
change.
C
C
C
Name
of
a
right
now,
where
we
push
stuff
into
the
Linux
clients
that
wasn't
compatible
with
the
spec,
so
we
had
to
go
change
suspect.
Luckily,
we
could
do
it
at
the
time.
So
I
want
to
get
I
want
to
have
the
model
where
we
get
the
spec
mostly
done.
We
implement
the
code
and
then
we
go
fix
the
spec
up.
So
it's
working
match
the
code
base
and
I'm
hung
up
on
personally
on
implementing
the
week
consistency
model.
C
C
H
I
H
C
H
C
H
Mean
the
second
thing
you
described:
how
to
interoperable
implementations
before
finalizing
the
protocol.
That's
standard
operating
procedure
for
the
ITF,
so
that's
easy
to
agree
on,
but
it
doesn't
seem
to
be
my
experience.
Well,
yeah.
Jumping
the
gun
is
a
problem,
but
that's
perhaps
not
probably
in
the
procedure.
So
you
know
I
meant
we're
totally
in
agreement.
I
just
wanted
to
point
that
out.
I'm.
J
K
K
J
Okay
purpose
of
this
work
I'm
just
reminding
folks
what
we
are
doing
with
us
there's
a
Linux
implementation
of
a
file,
integrity
measurement
architecture,
and
we
would
like
to
be
able
to
store
this
integrity
measurement
metadata
on
NFS
servers
using
either
a
standard
extension
NFS.
Is
there
question,
okay
or
or
a
sidecar
that
sidecar
RPC
protocol?
J
J
So
there
was
some
objections
from
Craig,
Averhart
and
Spencer
Shepler
that
you
know
if
the
if
the
metadata
format
isn't
described
somewhere
and
broad
implementation,
that
is
non
linux,
implementations
would
be
difficult
to
produce,
there's
also
hint
at
a
legal
issue
which
I'll
get
to
in
a
minute.
So
at
that
point,
progress
on
this
document
was
essentially
stopped
and
the
request
as
I
understand
it
was
for
a
metadata
format,
specification
be
provided.
Maybe
in
this
document
or
maybe
in
another,
my
choice
was
in
another
document
we'll
get
to
that
in
a
minute.
J
So,
as
I
started
working
on
the
metadata
format
document,
we
realized
that
there
were
some
legal
challenges,
because
this
was
only
there's
only
a
code
implementation.
There
is
no
specification
that
we
could
find
anywhere
there
there's
some
online
documentation
in
the
form
of
wikis
and
whatnot,
but
there
really
is
no
specification.
J
J
We
could
work
with
the
Linux
Foundation
to
identify
the
original
code
contributors
and
and
request
their
permission
to
relicense
the
contributed
code
under
GPL
and
BSD
instead
of
just
GPL
v2
only,
and
then
that
would
that
should
enable
us
to
contribute
the
format
specification
to
the
ITF
yeah.
The
other
two
bullets
on
here
are
really
I,
guess
nonsense.
I
mean
there.
This
is
kind
of
the
only
alternative
that
makes
sense
unless
someone
else
has
an
idea
here.
H
J
J
J
H
J
So
this
slide
kind
of
described
what
the
format
requirements
are.
So
if
we
were
to
create
a
new
neutral
format,
it
would
would
have
to
adhere
to
these
requirements.
It
would
have
to
be
extensible,
it
would
carry
a
signed
checksum
and
the
checksum
would
be.
The
hash
would
be
computed
via
a
standard
hash.
Algorithms
like
shot
256,
so
I,
don't
think
that
that's
I,
but
that
sounds
feasible.
J
A
neutral
on
neutral
format
sounds
feasible
based
on
these
requirements,
I
think
it
wouldn't
difficult
to
do
and
it
would
certainly
get
around
our
legal
issues
so
currently,
I
just
want
to
describe
the
legal
status.
Really
quick
of
the
current
effort.
I
am
working
with
a
lawyer
at
Oracle
who
is
in
contact
with
the
Linux
Foundation,
there's
already
plenty
of
Linux
kernel
code
that
is
under
dual
license.
J
Mr.
Tapie,
you
were
aware
of
probably
a
lot
of
that
or
an
author
of
it,
for
example,
in
the
RDMA
stack.
So
that's
that's
not
out
of
the
realm
of
possibilities.
All
of
the
authors
that
we've
been
identified
be
able
to
that.
We
have
been
able
to
identify,
are
still
active
contributors
and
I've
been
in
touch
with
most
of
them.
J
No
one
has
objected
to
this
process.
None
of
them.
None
of
the
authors,
have
objected
to
the
process
so
that
that
process
is
ongoing
in,
but
unfortunately
it's
kind
of
it
doesn't
have
a
determined
endpoint,
we're
still
just
working
on
it
and
seeing
where
it
goes
so.
I
do
have
a
metadata
format
document
that
I
can't
share
because
sharing
it
would
effectively
be
a
contribution,
the
ITF,
and
that
would
put
that
contribution
under
the
ITF
code
components
license,
which
we
cannot
do.
J
J
J
And
I've
had
some
conversations
with
the
with
the
folks
who
are
actively
working
on
the
Linux
ima
implementation,
and
we
think
that
for
remote
file
systems,
we
will
need
to
have
internal
Merkle
trees
on
the
clients
so
that
they
can
efficiently
manage
changes
to
small
parts
of
files.
Large
files,
like
object
code
repository
that
where
there
would
be
changes
in
in
small
parts
of
files-
and
we
really
don't
want
to
break
the
entire.
J
J
We
really
can't
do
that
in
the
fess,
but
we
could
store
say
a
signed
root
of
a
Merkel
tree,
and
that
would
be
enough
for
the
client
to
reconstruct
the
Merkel
tree
when
it
loads
a
file
into
memory,
and
that
would
make
things
more
secure
and
more
efficient.
So
that's
where
we
are.
Are
there
any
questions.
B
J
H
K
J
Okay,
so
this
is
a
sort
of
a
an
overview
of
our
PC
over
already
May
version.
I
know
that
this
is
not
an
interesting
topic.
A
lot
of
people
there's
a
lot
of
detail
on
this.
We
can
drill
into
the
detail
or
we
could
get
to
the
interesting
questions,
I'm,
not
sure
what
those
are
so
I'm.
Looking
for
some
feedback
from
the
audience.
What
are
you
most
interesting
in
the
hearing
about
here?
J
H
E
J
B
J
J
So
there
are
several
documents
in
question
here.
The
two
most
interesting
ones
are
the
ones
that
are
being
worked
on
at
the
moment
are
the
RPC,
our
DMA
version,
2
document,
which
defines
the
new
version
of
the
protocol?
That's
a
working
group
document
and
we
do
have
a
milestone,
as
Dave
mentioned
before.
J
J
So
RPC
over
already
May
version,
2
manages
to
fold
in
the
work
of
two
previous
documents.
One
is
RFC
8167,
which
defines
a
back-channel
operation
for
our
DMA
transports
and
the
other
one
is
the
capability
probing
mechanism.
That's
right
now
in
the
RF
is
RFC
editor
q
CM
private
data
will
apply
only
to
RPC
over
our
team,
a
version
1
because
we've
folded
that
mechanism
into
RPC
I've
already
made
into
as
a
part
of
the
of
the
protocol
itself,
and
so
we
won't
be
doing
capability
probing
using
the
private
data
connection
measure.
Private
data.
J
So
one
of
the
first
motivations
for
a
version
2,
is
to
address
some
of
the
performance
shortcomings
of
RPC
over
our
enemy
version.
1,
the
default
in
line
threshold
for
version
1
was
a
kilobyte,
that's
obviously
too
small
for
some
of
the
nfsv4
operations
like
open,
getattr
and
look
up
that
might
include
significant
amounts
of
data.
For
example,
if
you
have
a
get
at
or
in
an
open
compound,
it
might
be
requesting
things
like
security
labels
or
ackles,
or
things
like
that.
J
We
also
wanted
to
be
able
to
add
in
the
ability
to
extend
the
the
transport
protocol
as
we
recognize
new
limitations
or
or
or
want
to
fix
problems
in
the
protocol.
For
the
same
reason,
we
have
minor
versioning
in
NFS.
We
wanted
to
have
a
certain
amount
of
extensibility
this
to
this
transport
protocol
as
well.
J
J
Requester
has
to
figure
out
exactly
how
large
the
reply
possibly
could
be
in
then
provision
those
resources.
There
are
plenty
of
corner
cases
in
upper
layer
protocols
where
that
is
difficult,
or
even
impossible
to
do
so.
We've
added
some
mechanisms
in
RPC
/,
nama
version
2
that
Britt
deuce
or
eliminate
the
need
for
reply.
Size
estimation,
as
I
mentioned
before
we
have
a
new
upper
layer,
binding
version
that
is
particularly
for
NFS
or
for
NFS
on
RPC.
J
Over
already
May
version
2
and
as
I
mentioned
reply
size
estimation,
requirements
are
suitably
relaxed
or
eliminated
in
this
in
this
version
for
RPC
you've
already
made.
So
we
can
change
the
language
there,
at
least
in
the
upper
layer
binding
as
we're
working
on
our
PC
on
TLS.
We
realize
that
we
would
need
to
have
some
peer
authentication
mechanisms
built
into
the
RPC
over
already
made
transport,
and
so
last
year
we
decided
to
add
that
ability
to
RPC
of
our
team
a
version
2
since
that
RPC
on
TLS
doesn't
actually
have
a.
J
J
J
I
can
go
into
a
little
more
detail
here,
but
you
know
okay
I
mentioned
before
that
we
have
the
new
ability
to
exchange
transport
characteristics
like
what
we
used
to
call
transport
characteristics
are
now
called
transport
properties.
Basically,
at
the
beginning
of
a
connection
before
RPC
traffic
is
exchanged,
there's
a
transport
property
exchange
that
carries
the
capabilities
of
both
peers
so
that
they
can
sort
of
understand
the
limitations
on
both
sides
host
death.
On
occasion,
peer
authentication,
that's
at
the
bottom
of
this
table
is,
is
one
of
those
things
that's
exchanged,
so
it's
an
opaque.
J
That's
not
really
part
of
the
NFS
family
protocols,
but
some
RPC
protocols
do
that.
Another
case
is
where
retransmission
is
necessary:
that
screws
up
version,
one
credit,
accounting
and
probably
the
most
important
and
interesting
example-
is
the
ability
to
send
multiple
messages
and
get
one
response,
and
that
would
be
needed
to
support
message.
Aining,
that
is
a
call
that's
larger
than
one
rd
may
send,
could
be
sent
in
multiple
sins.
The
receiver
would
but
Nate
those
messages
together
and
reconstitute
the
call.
B
H
J
J
J
Okay
message:
continuation
is
a
kind
of
a
big
deal.
It's
the
ability,
as
I
mentioned,
before,
to
construct
a
a
series
of
already
Masons
that
convey
single
large
RDM,
a
large
RPC
message.
So
we
have
a
very
simple
way
of
doing
that.
We've
got
a
Flags
field
in
our
teammate
in
the
our
team,
a
transport
header
now
and
just
set
a
bit
that
says,
there's
more
to
come
with
this.
With
this
message.
B
J
J
J
E
J
I
mean
I
kind
of
like
you
know,
in
the
other
direction.
You
know,
we've
got
a
reply
chunk,
which
is
you
know.
Basically,
that's
the
sort
of
converse
of
positions
or
a
region
and
the
it
a
reply.
Chunk
has
significantly
less
ambiguous
than
a
positions
or
a
reach.
Uncas
and
one
of
the
things
I've
been
sort
of
fantasizing
about
is
actually
getting
rid
of
positions
or
a
tree
trunks
and
yeah
all.
H
Right
so
for
the
for
the
uninitiated,
the
position
zero
read
chunk
is
intended
to
provide
a
way
for
very
large
requests
to
be
transmitted
to
the
server
and
basically
it
sends
an
empty
request
with
a
pointer
to
the
request.
But
the
server
then
fetches
via
read
and
a
reply
chunk
is
like
Chuck,
mentions
kind
of
the
opposite
provides
a
buffer
that
the
server
can
opportunistically
RDMA
right
into
and
they're
both
really
awkward.
They
were
designed
for
compatibility
with
corner
cases
in
the
protocol.
I
would
love
to
see
them
go
away.
H
J
So
anyway,
this
this
slide
mentions
a
couple
of
corner
cases
that
are
kind
of
interesting.
With
a
with
the
current
reagent
formats,
we
can
have
gaps
in
the
RPC
message.
If
I
guess,
that
would
be
a
bug
in
the
requester,
but
there's
no
I'm
sure
servers
aren't
prepared
to
deal
with
gaps
if
broken
clients
that
is
and
I
feel
like.
H
J
A
H
J
J
Okay
last
slide
and
more
review
always
helpful.
I
encourage
it
strongly
for
my
documents
and
for
everybody
else's
I'm
certainly
lacks
in
that
regard.
So
review
review,
review,
review,
I
haven't
done
any
prototyping
aversion
to
stuff,
yet
I
save
the
remote
invalidation
work.
I've
done
the
inversion,
one
that
drove
the
CM
private
data
document.
A
A
A
H
J
J
H
J
B
A
J
H
The
status
of
soft
I
warp
and
linux
is
that
it
is
upstream,
so
it's
in
a
standard
current
as
of
about
six
months
ago,
I
think
and
I
mean
actively
maintained.
Most
most
people
report
that
it
functions
well,
it
interrupts
rates
with
hardware
implementations.
Yes,
so
you
know
pretty
good.
I
would
say
yeah.
J
It
was
that
was
a
actually
something
that
I
had
been
driving
the
our
team,
a
Linux,
our
team,
a
community
to
adopt
simply
because
this
this
testing
issue
has
been
a
present
for
since
we've
started,
doing
NFS
I've
already
made
testing
at
these
events
and
I.
Think
soft
I
warp
is
something
that
everybody
can
get
around,
except
maybe
Solaris
just
because
they
don't
seem
to
have
developer
resources
to.
B
Yes,
I
wasn't
too
worried
about
all
that
I
was
not
involved.
I
am
mostly
looking
good
I
work
for
from
charity
or
debt
that
we
have
and
that
the
the
one
that
it's
probably
enough
may
support.
Maintaining
here
oxide
think
about
yourself
only,
but
it
good
for
to
know,
because
if
I
want,
we
want
any
interruption.
I
won't
have
a
server
in
my
laptop
Tarkio
cards.
Oh
right.
H
B
J
A
No
way
we
deal
with
this
is
the
author
or
the
intern
you're.
The
editor
I
figured
that
when
he
wants
to
do
that,
I
think
you
from
what
from
the
presentation
there
aren't
that
many
open
issues
I
think
we
should
have
some
discussion
and
then
you
should
decide
when
you
think
is
think
W
GLC
is
appropriate.
J
A
H
J
Okay,
I
guess
I'm.
The
next
slot
is
that
right,
you
are
okay,
this
will
probably
be
quick.
I,
don't
have
any
slides
for
this.
One
essentially
I
was
hoping
to
ask
for
any
further
comments
or
concerns
about
the
RPC
TLS
document.
The
ad
review
is
quite
vigorous.
I
think
the
document
is
in
much
better
shape
than
it
was
before
linked
to
80
reviews.
So
now
is
the
opportunity
for
anyone
to
speak
up
and-
and
you
know,
make
any
comments.
D
It
sent
replied
to
this,
but
I
mean
you
maybe
haven't
read
it
because
I
did
it
during
the
meeting
so
far,
I
think
there's
one
aspect
of
this
usage
of
the
connection
IDs
ALS,
which
is
it
does
sync
our
overhead
and
that's
my
question
to
the
working
group.
This
is
more.
Is
it
useful
to
use
it
from
the
perspective
or
will
it
cause
issues,
and
maybe
my
understanding
of
of
how
an
affair
cetera
how
you
would
you
assist
infidel
Percy
in
many
cases,
but
I
would
expect
that
you
have
a
sir
report
which
lists
houses.
D
J
D
Yeah
so
I
mean
the
aspect
of
this.
Is
that
you're,
if
you're
having
this
I
mean
that
you
actually
the
correction
state
in
place
and
and
have
this
and
you
occasionally
do
this
really
short
requests
I,
don't
know
how
many
simultaneous
users
across
this
state
is.
It
becomes
the
question,
but
I,
don't
think
overhead
is
massive.
It's
probably
I
mean
four
bytes
would
give
you
for
me
billion.
B
D
Maybe
the
easiest
way
is
not
to
say
anything
more
than
that
this
exists
and
I
don't
think
it's
it's
it's
you
can
either
use
the
connection.
Id
or
not,
I
mean
basically
detail
s
1.3,
it
seems
to
be
an
existing
part
of
it.
It's
like
it's
gonna
be
up
to
it,
so
every
man
negotiate
if
it's
gonna
use
it
or
not.
So.
J
A
D
J
A
I'm
gonna
be
can
can
people
see
my
screen
now
they're
still
seeing
chucks
chuck
screen
all
right,
yes,
I'm
now
the
presenter,
okay,
so
I'm
gonna
do
a
really
originally
three
separate
or
then
four
separate
talks,
but
I
just
merged
into
one,
because
they're
all
related
to
the
same
thing,
which
is
documents
related
to
RFC
56-51
bit.
Anything.
A
K
A
B
G
A
A
First
of
all,
the
version
approach
is
pretty
1
778
it's
wrong
and
confusing
the
confusion
that
Tom
addressing
RC,
84
34
is
not
clarified,
and
we
have
now
pending
some
chain
substantive
changes
in
RFC
56:51,
but
we
still
need
a
single
document
explaining
defining
Ana
54
that
one
and
also
the
internationalization
section
is
based
on
string
prep
with
no
connection
to
actual
implementation.
So
it's
really
kind
of
a
mess.
Now
everyone
knows
what's
valid
and
what's
not
valid
is
but
to
a
neophyte.
A
A
We
need
the
updating
revision
revision,
there's
no
threat
analysis,
the
the
vague
security
goal
of
supporting
news
on
the
Internet
and
lack
of
attention
to
monitoring
threats
and
uses
losses
in
the
clear
with
no
authentication
of
quantity.
Struzan
is
optional.
Action
of
the
word
optional
is
not
is
using
RFC
7230,
but
the
word
optional
is
not
used
into
specifics.
What
it
does
say
may
influence
so
now
that
we
have
our
PC
TLS
that
the
Chuck
intron
has
provided
for
us.
We
have
the
ability
to
improve
things
without
changing
the
ability
for
that
one
protocol.
A
Also,
we
have
an
accumulation
of
errata
reports,
including
some
that
were
officially
rejected
for
reasons
that
that
that
we
can
go
into
given
they
have
changes.
Vinsol
changes
to
the
RFC
56-51,
the
arms
the
working
group
group
has
agreed
to
it,
but
these
changes
are
not
documented
anywhere,
except
on
the
working
group
list.
There's
some
emails
that
Ron
pointed
me
to.
We
all
agreed
that
something
had
to
change,
but
it
was
never
changed
and
therefore
our
C
56-51
is
kind
of
outdated.
A
Well,
given
that
said
that
I
I
think
this
can
be
done,
the
people
say
no
having
trouble
with
that,
but
lots
of
stuff
is
already
done.
Many
changes
are
already
documented
well
in
existing
RFC's.
In
other
cases,
the
working
group
has
made
clear
decisions
that
need
to
be
explained.
We
have
reasonable
treatment
of
internationalization
in
RFC,
75,
30
and
RPC
TLS
could
be
the
basis
for
a
reasonable
security
approach.
A
So
I
think
we
need
to
come
to
terms
with
with
what
I
perceive
to
be
a
post,
75
30
trauma
I
mean
it
was
very
long
and
very
onerous
thinking
we
finally
got
done
and
I
think
it's
some
time
after
that
we
were
thinking
of
well
gee.
Maybe
we'll
do
this
again,
maybe
we'll
somehow
do
small
documents
that
won't
work.
So
I
conclude,
even
though
that
effort
was
a
drag
when
you
consider
where
we
would
be
now
if
we
had
not
done
it,
and
the
working
group
needs
to
work
together
to
address
these
issues.
A
I
think
I
presented
reasonable
plan.
The
plans
about
how
we're
do
it-
and
we
have
to
part
of
it-
has
to
be
a
serious
review
effort
for
submission.
There's
too
many
places
where
we
just
so
say,
think:
oh,
we
we're
hands
and
we
don't
want
to
deal
with
some
of
the
parts
of
the
speck
that
aren't
clear
and
we
just
make
sure
that
we're
going
for
with
a
clear
speck
right
now,
the
all
right,
let's
see.
A
Because
we
have
two
areas
that
were
the
same
envy,
Porto
and
B
4.1.
We
have
to
have
multiple
documents.
One
is
internationalization,
will
be
the
same
in
4.0
and
4.1,
and
we
need
a
new
document.
Just
to
describe
internationalization
in
NF
is
e4
as
a
whole,
and
security
is
in
bad
shape
for
ball,
minor
versions
that
make
sense
to
provide
an
NFS
before
wide
prison.
A
A
I'm
expect
to
produce
an
informational
ID
about
our
options
and
choices
in
in
in
in
in
Surrey
in
the
security
area.
Now
expect
that
to
be
adopted.
As
an
internal
working
group
document,
often
we
had
we've
had
information,
informational,
IDs,
and
then
we
go
through
this
process
of
thinking
about
producing
as
information
on
IFC
there's
no.
E
A
Then
we
have
to
address
our
c
v.
6
bits
prod,
we'll
start
with
limited
ID
will
use
the
RFC
resulting
from
the
setscrew
process
and
jazz
will
start
bowel
start
and
addresses
limiters
of
well
understood
issues.
Isn't
that
family?
These
things
that
we're
talking
about
the
is
our
the
the
versioning
issue:
referencing,
the
security,
new
security
and
and.
A
An
internationalization
document,
and
and
one
do
that
that
is
working
with
a
Kurd
and
then
I,
would
ask
some
help.
I
need
some
help,
your
time
about
addressing
RFC,
84,
34
and
PN
FS
clarification
and
there
there
are
all
time
led
about
selling
products
and
then
we'll
need
a
major
review
effort
before
submission.
So
that
is
that
is
amazed.
I
lift
the
year
anyway.
A
J
J
About
why
we
would
include
PMF
s
in
the
best
document,
rather
than
having
that
also
separated
into
a
different
document.
What
what
were
you
thinking?
I
didn't
hear?
Well
we're
breaking
out
security
and
internationalization
I'm
wondering
if
PMF
S
should
be
in
a
separate
document
than
we've
we've
already
gotten
some
RFC's
in
this
area.
Why
do
you
think
it
needs
to
be
organized
so
that
the
PMF
s
stuff,
that's
in
56
61-
needs
to
continue
to
be
in
56
61.
This.
D
Exactly
I
think
actually
one
other
aspect
of
this
which
you
haven't
brought
up
is
actually
to
take
the
outcoming
RFC
C,
okay,
what
kind
of
boundaries
inside?
Can
you
actually
just
chop
this
document
up
into
a
couple
pieces
which
makes
it
rather
than
this
700
page
bounce
through
this,
into
something
at
least
a
little
bit
more
more
manageable?
Yes,
its
results
and
such
reference
may
be
cross
talk
between
documents,
but
it
might
make
everyone's
life
easier,
especially
if
there's
any
future
updates
in
future.
That
would
need
it.
Okay,.
A
Well,
if
someone
has
a
that's
an
idea,
but
so
as
a
concrete
plan
to
do
that,
we'll
consider
it,
but
right
now,
I,
don't
know
because
I
think
some
of
the
cases,
for
example
we're
not
PMF
s.
Well,
you
makes
document
either
easier
to
review,
but
I'm
not
sure
that
that's
a
good
thing
make
the
diet
may
make
the
document,
but
just
by
ignoring
all
the
PMF
s
cases,
you
don't
have
to
review
those
but
they've.
B
K
B
K
Say:
yay,
because
that
that's
my
worry
Magnus
Magnus,
the
the
single
document
part,
was
the
absolute
required
part
of
NFS.
The
separate
documents
historically
have
been
either
the
other
protocols
or
optional
laya
mechanisms
that
were
not
required
for
competitive,
aware
of
compliance
with
the
protocol
so
yeah,
but.
K
D
D
K
K
D
M
D
K
D
Would
let's
let
me
restate
saying
I
think
you
should
think
about
this
document
structure
is
for
how
you
make
this
process
as
easy
as
possible
for
you
to
complete
with
as
little
effort
as
possible.
Then
it's
good.
If
you
like,
the
is
you
etc?
Actually
can
I
mean
that's
likely.
One
point
to
keep
in
the
doctor
together
is
that
if
you
can
actually
do
it
in
a
reasonable
way,
you
can
ignore
all
the
section
that
hasn't
changed
cetera,
which
makes
somebody
reviews
for
a
lot
of
people's
much
easier,
already
has
looked
at
it.
I.
K
F
You
said
several
times-
or
you
mentioned
several
times
in
FS
before
over
TLS
and
I-
want
to
repeat
what
the
Tom
Hanks
said
earlier
today,
that
we
changed,
create
a
spec,
then
do
implementation
in
the
find
out
that
the
implementation
is
impossible,
and
then
we
modified
the
spec.
So
now,
what
is
the
rationale
to
put
this
NFS
or
over
TLS
into
into
spec?
If
there's,
no
implementation,
which
uses.
C
F
H
So
it's
I
mean
it
has
to
be
written
down
somewhere
for
multiple
implementations.
To
attempt
to
implement
the
the
ITF
process.
Normally
will
publish
a
drafts
back
and
will
allow
implementations
to
proceed
and
if
they
prove
the
spec-
and
you
know,
there's
no
further
changes
well,
it
gets
published
as
a
final
version,
so
I
mean
we.
C
H
It
can't
be
reviewed.
Magnus
has
a
good
point
on
that.
I
think
you
know.
In
addition,
the
reader
can't
consume
the
damn
thing
right.
So
breaking
it
makes
really
good
sense
to
me.
You
need
a
long
ways,
but
you
know
it's
like
I
would
not
worry
about
writing
down
a
draft
protocol.
That's
the
whole
point
of
writing
it
down.
Everybody
agrees
on
it
and
gets
it
to
the
point
where
they
start
to
implement.
H
D
Mean
mom
well
at
one
point
about
this
rule
related
to
the
real
security
solution.
You
need
a
security
solution
that
stands
up
to
more
than
scrutiny.
That's
that's
gonna
be
a
requirement.
This
document
is
not
gonna,
be
published
without
reaching
that
goal
and
I
think
so,
if
that's
TLS
or
if
it's
something
else,
that's
that's
up
to
you
to
decide,
but
you
need
to
have
something
which
fulfills
more
than
security
expectations
when
it
comes
to
security.
A
All
right
from
a
time
point
of
view,
I
think
I
have
to
go
ahead
with
internationalization
as
says
as
brighness
said:
he'll
figure,
we'll
figure
out.
How
we'll
have
the
working
group
address
this
divided
up
issue,
I.
Think
from
time
point
of
view.
The
appropriate
time
to
do
is
when
we
consider
making
the
best
document
a
working
group
document.
Let's
go
on.
Okay,.
A
Internationalization-
that's
part
of
this
long
so
before
there
is
a
thing
that
I
thought
of
doing
about
doing
was
this
propagate
nationalization?
That's
in
RFC!
Seventy
five!
Thirty,
that's
been
very
nice.
We
have
an
efficient
Coronado
installations,
did
not
match
our
see.
Thirty.
Five
thirty
did
match
RFC.
Seventy
five.
Thirty,
it
turns
out
the
report
at
one
implementations
do
the
same
thing:
RFC
56:51
was
written
matching,
RC,
thirty,
five
thirty,
which
would
have
this
string
prep
based
thing
and
no
implications
match
it.
A
That
was
handling
the
International
analyze
domain,
their
main
names,
and
so,
when
I
found
that
I
took
the
arts,
what
was
in
RFC
7230,
which
is
valid
to
confirm
conformed
to
it?
That
was
was
that
it
was
a
2003
now
many
of
the
things
that
in
in
documents
the
server
are
supposed
to
do,
including
those
that
says,
should
do
which
I
can
are
an
absolute
document.
A
There's
no
way
I
can
produce
a
new
document
that
says,
do
those
things
so
I
didn't
it's
allows
you
to
go
through,
but
I
don't
think
it's
appropriate
from
the
document,
even
if
the
ISP
would
accept
it,
which
is
a
kind
of
doubt
so
I
need
to
revise
the
International.
They
men
handling
to
match
that
for
2008
and
while
warned
of
the
possible
compatibility
issues,
well,
I
really
don't
think
exists,
but
theoretical
exist.
So
that's
the
401.
Now
that's
where
we
are
with
the
with
internationalization.
A
So
we
need
a
path
going
forward
like
I
need
people
to
review
the
legacy,
but
I
have
been
trouble
doing
that,
because
a
lot
of
people
don't
want
to
or
not
able
to
review
internationalization,
so
I
think
we
may
need
to
find
out
how
to
get
input
from
internationalization
experts
outside
the
working
group
and
I.
Don't
know
how
do
that,
but
that's
a
necessary
thing.
We
should
do
also.
A
We
need
input
from
implementers
about
how
existent
implementations
of
before
deal
with
the
internationalized
nationalised
is
a
domain
name
issues
if
they
do
it
all
I'm
looking
to
get
to
a
working
group
docket,
but
I'm,
not
sure
how
many
issues
will
be
required.
I
need
to
pick
a
milestone
and
I've
picked
December
of
the
end
this
year
and
I.
Think
that
should
be
safe
enough
for
the
internationalization
part.
A
A
A
As
Magnus
noticed,
this
is
essential
and
although
I
hadn't
put
together,
I
think
he's
right
that
you
know.
If
we
don't
address
this,
it's
we're
not
gonna.
When
I
know
it's
going
to
publish
this,
so
we
have
a
series
of
in
the
current
dog
and
we
have.
We
have
certain
documentation
problems
and
we
have
some
substance
and
problems.
The
documentation
problem
is,
there
is
no
threat.
Analysis
I'm,
not
sure
how
RFC
56:51
was.
A
It
was
approved
without
a
trainer
supposedly
they're
all
supposed
to
have
them,
but
we
don't
have
one
and
the
goal
is
secure
use
on
the
internet.
Now
it's
not
made
clear
if
that
has
been
in
the
environment,
whether
it's
been
realized
and
here's
the
spoiler
alert.
It
hasn't
been
now,
there's
a
couple
of
major
assumptions
and
problems
from
implantation.
There's
lack
of
encryption
use.
A
There
is
a
provision
for
encryption,
but
almost
nobody
ever
does
it
and
the
extensive
use
of
offices
in
the
clear
without
authentication
of
the
clients,
and
therefore
you
have
the
possibility
that
anybody
can
simply
say
here's
a
request
under
office
and
the
server
has
no
choice.
There's
no
real
choice
but
to
execute.
A
A
The
problem
is:
yes,
that's
a
requirement,
but
really
it's
not
clear
what
a
sit
here.
Your
consideration
section
should
say
without
a
threat
analysis
in
ourseives,
seventy
five,
thirty
and
fifty
six,
fifty
one
just
to
be
a
series
of
security,
related
observations
and
well
yes,
but
doesn't
really
tell
you
what
kind
of
security
you
have
well,
it's
the
way
or
someone
can
compute
the
security
is
very
good.
A
A
A
A
A
A
G
K
K
K
K
K
H
H
H
M
D
G
E
D
A
Opposite
of
a
means
of
authentication,
although
usable
week
it's
officially
optional,
but
it's
really
not
possible
to
ship
the
server
which
doesn't
support,
as
almost
nobody
would
use
it.
So
without
authentication
of
the
client,
the
clients
authentication
of
the
user
cannot
be
trusted.
So
the
reality
here
is
that
offices
is
an
effectively
mandatory
to
implement
means
of
non
authentication
which
is
optional
for
attackers
to
use.
Unfortunately,
so
that's
the
sure's
need
to
change,
and
the
interesting
question
is
how'd.
You
change
it
now
we're,
despite
that
problem.
A
We're
kind
of
lucky
in
that
truck
and
Tron
had
provided
RPC
TLS
to
be
a
good
basis
for
them.
So
now
that
we
have
assists,
we
have
to
get
with
possibilities
for
change.
One
might
be
getting
rid
of
it,
I'm
sure
the
people
in
the
security
I've
heard
Monsieur
director.
They
would
love
to
do
that,
but
it
really
I
think
I
think
we're
gonna
think
about
it
a
little
bit
and
find
out.
This
was
not
really
possible.
It's
possible
the
deprecated
in
some
way
saying
should
not,
but
it
doesn't
prevent
people
from
using
it.
A
A
D
But
my
understanding
is
that,
as
long
as
you
actually
have
Transport
Security
between
the
end
pose
and
host
providing
the
authorization
to
or
trying
to
make
a
statement
about
there,
its
its
source,
identity,
all
sorts
of
think
Asian,
it's
it's
probably
fine.
As
long
as
you
have
the
innominate
or
its
used
Transport.
L
A
A
So
so
you
need
to
specify
we
have
the
facilities
not
be
CTLs,
but,
as
we've
discussed,
we
needed
appropriate
policies
for
RPC
LS
used
by
our
v4,
for
encryption
and
for
client
authorization,
and
there
are
a
number
of
decisions
that
need
to
be
made
and
I'll
try
to
go
over
those.
Although
I
only
have
11
minutes
left
yeah.
D
What's
called
a
statement
about
your
identity
from
the
client
side
and
the
server
and
the
client
can
trust
that
is
talking
to
the
intended
server
in
that
environment.
You
might
not
require
client
devices
until
client
of
that
hard
cry.
Encrypting
a
client
authentication,
because
the
password
is
that
drone
similar
secrets
might
be
sufficient,
because
now
he
moved
from
environment
where
it
was
possible
to
easily
snoop
them
to
environment,
where
they
really
should
be
secrets.
A
L
A
A
Cajun
we
mean
two
things,
I
think
typically
RPC
trj,
the
RPC
second
RPC
GSS
provides
authentication
of
the
crime
user.
The
authentication
we
talked
about
that
provided
by
RP
CLS
is
authentication
of
the
client
host
and
those
that's
when
I
say,
kleiner
of
faith
being
here
in
Southend
ages
of
the
client
host.
D
A
A
Okay,
alright,
so
here
this
slide
presents
what
I
believe
to
be
the
framework
we
need
for
a
new
approach,
he's
a
based
on
threat.
Analysis
needs
to
deal
with
two
major
security
issues:
the
lack
of
encryption
and
the
exclusion
on
a
thing,
both
of
which
has
been
partially
addressed.
The
framework
has
been
provided
by
our
PC
TLS
and
will
I
think
will
be
used,
our
PCTs,
whose
additional
requirements
that
are
an
associated
for
specific
and
their
in
making
these
changes
to
do
this,
there's
some
complicated
factors
to
do
so.
A
Well,
you
know
often
we
talk,
we
need
to
change
the
requirements.
You
know
we
we
we
said,
we
said
this
is
optional
and
we
need
to
change
it.
So
it
should
not.
But
I
don't
think
we
can
do
that
because,
first
of
all,
you're
going
to
create
new
requirements
for
new
facilities
like
gee,
you
have
to
use
RPC
TLS
is
well.
Maybe
someone
hasn't
done
it
yet,
and
you
can't
really
say
you
required
to
do
something
that
you
can't
do
and
we
need
to
address.
A
A
One
of
the
goal
is
secure
use
on
the
internet
and
it's
been
assumed
by
a
lot
of
people
that
the
typical
networks
will
work
on
with
with
incumbent
in
that
networks.
We
don't
need
that
love
when
you
pretty
much
need
that
level
of
security,
because
you
know
if
you
are
not
working
environment,
essentially
where
everyone
has
the
same
password
that
you
want
to
protect
user
affixes
would
be
as
file
and
the
fact
that
they
work
the
same
company
does
not
do
that
and
I
think
we
can
stop.
A
Our
PC
to
us
is
an
encryption,
is
a
good
good
fit,
but
but
there
are
other
forms
of
encryption
that
either
we
are
provided
or
will
be
provided.
One
is,
is
encryption
encryption
in
the
RPC
over?
Are
you
may
adapt
resolve?
We
provide
encryption,
which
you
don't
see
and
I
think
that
needs
to
be
allowed
and
also
probably
eventually
will
have
to
less
equivalent
such
as
quick.
So
we
need
to
formulate
or
a
quantity.
You
have
an
authentication,
but
hey
you
have
encryption
but
needs
to
be
sufficiently
flexible,
so
that
feel.
A
Well
again,
the
problem
with
that
it's
a
valid
choice
but
I'm,
not
sure
we
can
just
say
should
not,
but
we
have
to
give
some
indication
of
what
the
problem
is
and
if
you
do
that,
I
don't
care
about
a
term
being
in
all
capital
letters.
But
if
you
do
this,
what
you
expose
yourself
to
that's
our
obligation
right,
stick.
A
All
right,
this
is
client
I,
think
Haitians.
We
need
by
that
I
mean
a
fan,
deviation
of
the
client
host
and
we
have
an
issue
about
where
that,
where
that
description
appears,
I've
been
thinking
of
it
in
the
before
security
document,
but
it
could
appear
as
a
correction
to
RC
55:31,
since
there
is
an
extensive
but
not
very
clear
description
of
Ott's,
it's
in
Appendix
A
to
RFC
it's
about
31.
A
A
All
right,
another
issue
that
we
have
is
is
before
one
specific
thing
of
state
and
session
protection.
We
have
SP,
we
events
before,
none
which
is
most
googled
employed,
but
there's
no
protection
about
that
and
you're
exposed.
Basically
that
someone
could,
just
if
you
don't
have
an
encryption.
Certainly
you
can
someone
can
get
your
session
ID
and
he
can
make
a
museun
issue
request
whether
you
know
you
just
slot
ideas
make
you
so
that
you,
whenever
you
have
a
request,
it
has
the
wrong
sequence,
ID
and
he
doesn't
even
have
to
have.
A
A
Now,
if
you
do
have
client
on
vacation,
I
believe
and
I
think
Chuck
mentioned
this
once
you
can
avoid
the
need
for
s
before
Mac
read,
and
certainly
we
I
don't
know
if
we
delete
this
from
the
spec.
But
it's
before
SSP
has
never
been
implemented
and
I
think
with
client
eyes
that
kind
of
host
authentication
I,
don't
think
you
need
it
any
case.
That's.
A
Now
some
of
this
is
just
super
fancy
by
by
the
remark
the
remarks
that
Magnus
made
about
maybe
studying
this
document
up
but
I.
Think
if
we
do
that,
the
appropriate
time
to
do
that
would
be
when
I've
done
the
work
who
anticipated
in
the
the
personal
ID
and
we
would
make
a
decision
of
what
the
way
to
go
for
is
the
with
the
stands
tracked
documents
so
anyway.
I
think
that
that's
done
and
it's
almost
3
o'clock.
So
that's
it
for
me,
questions.
K
A
K
C
K
C
K
J
K
H
A
H
K
E
N
Had
a
question
this
is
mark
Bosque
with
regards
to
the
authentication
of
the
host
client
versus
the
user
on
the
host
client.
That
is
one
of
the
things
that
sort
of
needs
to
be
addressed
somehow
in
future
documents,
because
it
is
becoming
a
problem
where
we've
got
group
permissions
are
not
necessarily
enough.
There
are
actually
some
access
control
lists
that
it
would
be
desirable
to
be
reflected
that
are
per
user
and
so
being
able
to
authenticate
as
the
given
user.
That's
privileged
to
look
at
the
files
is
a
highly
desirable.