[nfsv4] Éric Vyncke's No Objection on draft-ietf-nfsv4-delstid-05: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-nfsv4-delstid-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-delstid/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-nfsv4-delstid-05

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Christopher Inacio for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

The text about `Discussion of this draft...` should not be part of the abstract
but be in its own dedicated section.

## Section 1

While the abstract contains `This document extends both NFSv4.1 (see RFC8881)
and NFSv4.2 (see RFC7863)`, this section only has `the revisions in this
document become an extension of NFSv4.2 [RFC7862]`. I.e., there is a
discrepancy at first sight.

Some explanations about `delegation stateids` will be welcome for the reader.

## Section 2

Should there be informative reference (or a warning in section 1.1 to re-use
terms from RFC xyz) for GETATTR, ... ?

## Section 3

What is `bitmap4`, while I am not a NFS expert, I would expect having some
terminology defined (see comment to section 2).

## Section 3.1

I am not familiar with XDR, but I wonder why the specifications are split in
multiple CODE brackets rather than a single one. Also puzzled by the use of
`///` as I read them as comments. Even section 6 does not explain why there is
a need for a sentinel.

## Section 5.1

Suggest to mention NFSv3 in the section title.

## Section 6.1

It does not really hurt repeating the code licensing but it is redundant with
"Copyright notice"

## Section 8

As I am not a NFS expert, I find strange that IANA registries are not used in
this document. But, if this is the authors/WG choice, then let it be.