Reporting of Errors via LAYOUTRETURN in NFSv4.2
draft-ietf-nfsv4-layrec-04

Like John, I wonder what 'resilver' means... (I am sure though that John knows)

"Abstract", paragraph 0
>    The Parallel Network File System (pNFS) allows for a file's metadata
>    (MDS) and data (DS) to be on different servers.  When the metadata
>    server is restarted, the client can still modify the data file
>    component.  During the recovery phase of startup, the metadata server
>    and the data servers work together to recover state (which files are
>    open, last modification time, size, etc).  If the client has not
>    encountered errors with the data files, then the state can be
>    recovered, avoiding resilvering of the data files.  With any errors,
>    there is no means by which the client can report errors to the
>    metadata server.  As such, the metadata server has to assume that
>    file needs resilvering.  This document presents an extension to
>    RFC8435 to allow the client to update the metadata and avoid the
>    resilvering.

Does this extension not change the behavior of how the client interacts with the metadata server? If it does, would this document not be updating RFC8345?

This document uses the RFC2119 keywords "OPTIONAL", "SHALL", "SHOULD NOT", "NOT
RECOMMENDED", "RECOMMENDED", "SHALL NOT", "SHOULD", "MAY", "MUST NOT", "MUST",
and "REQUIRED", but does not contain the recommended RFC8174 boilerplate.

Found IP block or address not inside RFC5737/RFC3849 example ranges:
"15.1.9.2".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 3
>  open, last modification time, size, etc). If the client has not encountered
>                                      ^^^
A period is needed after the abbreviation "etc.".

Thank you to Dale R. Worley for the GENART review.

** Section 2.2
  If the client does use the new functionality and the metadata server	
  does not support it, then the metadata server will most likely reply	
  with a NFS4ERR_BAD_STATEID to the LAYOUTRETURN.

How else might the metadata server respond if not with NFS4ERR_BAD_STATEID?

I presume “resilvering” is a term of art so widely understood by the intended audience of this document that it needs no definition.

Nit: s/behvior/behavior/

Thanks to Shuping Peng for the ARTART review.

I too wonder whether this should Update: 8435 or not. It depends on what the IETF thinks Update means.

I would argue that if this is a minor implementation effort, that perhaps an Update: clause is merited, to ping implementers to look at this feature to implement. If implementing this is a monumental effort, then perhaps an Update: is less suitable and this should be thought of as a standalone extension. From what I can see as an outsider, it seems more like the former one than the latter one?