Subject: [nfsv4] Review of draft-ietf-nfsv4-rfc5661sesqui-msns-01

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Sep 2019 15:38:34 +0000

Hi,

I have now done my review of draft-ietf-nfsv4-rfc5661sesqui-msns-01. The
review focuses on introduction, appendix and other things related to the
format of the update. I have also gone through the Diff to glance through
the changes.

1.	Section 1.1. 
Work would have to be done with regard to RFC8178 [61] with which
      RFC5661 [60] is curretly inconsistent, in order to arrive at a
      situation in which there would be no need for RFC8178 to update
      the NFSv4.1 specfication.

I would recommend that you include some words, either title or some summary
of what RFC 8178 is in this text as it is the first occurrence of the
reference. 
2.	The same comment as above also applies to the next paragraph in
respect to RFC 8434. 
3.	Section 1.1: Regarding the second bullet: 

        o  Work would have to be done with regard to RFC8434 [64] which

      curently updates RFC5661 [60].  When that work is done and the

      resulting document approved, the new NFSv4.1 specfication will

      obsolete RFC8434 as well as RFC5661.

a.	When it comes to updating this document, there are no purpose in a
single document. What I understand of the goal with creating complete RFCs
with updates is to avoid having to combine descriptions. However, if 8434 is
a self contained functionality it could actually remain as is, and simply be
normatively referenced by 5661bis as being part of NFS 4.1 protocol. Now, I
haven't read through the documents to understand if this is a possibility or
that integrating it is the obvious way forward. 

3.	What I wrote in 3. Is why there clearly is a possibility to resolve
i18n in a manner that applies to all minor versions .
4.	Section 1.1. I think this text should drop the use of a single
document in favor of talking about a set of authorative correct
specifications. I think you could consider the language Adam Roach uses in
https://datatracker.ietf.org/doc/draft-roach-bis-documents/ to motivate this
approach.
5.	Section 1.1: 
    There is a need for a revised treatment of security of in NFSv4.1.
      The issues with the existing treatment are discussed in  Appendix C.
Note the two "of" in first sentence.
6.	Section 1.1: I think the first paragraphs should be a bit more
explicit about that this is a limited scope update. I would suggest the
following:

The revised description of the NFS version 4 minor version 1 (NFSv4.1)
protocol presented in this update is necessary to enable full use of
trunking in connection with multi-server namespace features and to enable
the use of transparent state migration in connection with NFSv4.1.  This
document is in the form of a updated description of the NFS 4.1 protocol
previously defined in [RFC5661]. RFC5661 is obsoleted by this document.
However, the update has a limited and focused scope on enabling full use of
trunking, the need for these changes are discussed in Appendix A. Appendix B
described the specific changes made to arrive at the current text.

This limited scope update is applied on the main NFSv4.1 RFC is intending to
provide an authorative complete specification, the motivation for this is
discussed in [I.D-roach-bis-documents], addressing the issues within the
scope of the update. However, it will not address issues that are known but
outside of this limited scope as could expected by a full update of the
protocol. Below are some areas which are known to need addressing in a
future update of the protocol.

7.	Section 22: IANA Consideration
As this document is going to obsolete RFC5661 it will be necessary to
instruct IANA to update all registry entries and registry rules references
that points to RFC5661 to point to this document instead. 

Cheers

Magnus Westerlund

---

From: David Noveck <[email-masked]>
Date: Fri, 20 Sep 2019 12:14:25 -0400

On Fri, Sep 20, 2019 at 11:38 AM Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
>
>
> I have now done my review of draft-ietf-nfsv4-rfc5661sesqui-msns-01.
>

Thanks.

> The review focuses on introduction, appendix and other things related to
> the format of the update. I have also gone through the Diff to glance
> through the changes.
>
>
>
>
>
>    1. Section 1.1.
>    I would recommend that you include some words, either title or some
>    summary of what RFC 8178 is in this text as it is the first occurrence of
>    the reference.
>
>
I will do that.

>
>    1. The same comment as above also applies to the next paragraph in
>    respect to RFC 8434.
>
>
OK.

>
>    1.  Section 1.1: Regarding the second bullet:
>
>    1. When it comes to updating this document, there are no purpose in a
>       with updates is to avoid having to combine descriptions. However, if 8434
>       is a self contained functionality it could actually remain as is, and
>       simply be normatively referenced by 5661bis as being part of NFS 4.1
>       protocol. Now, I haven’t read through the documents to understand if this
>       is a possibility or that integrating it is the obvious way forward.
>
>
I think it is a possibility, although I'm not sure yet whether this is the
best choice.  My feeling, based on what we've seen so far of the
pNFS-related errata is that substantial work will be needed to clarify this
area of the spec so we cannot simple leave Sections 12 and 13 as they are
and leave 8434 as it is.   I'd really like to hear Tom's opinion on the
best way to proceed.   I can rework the paragraph to leave it open, for
now, about what approach to take.

>    1. What I wrote in 3. Is why there clearly is a possibility to resolve
> I don't see any reason for these to be different in 4.0 and 4.1.  Although
the transition from mnor version zero hanged lots of things, it did not
change this.   One possible problem is that if do publish "I18N in V4" RFC,
it is unclear how it will affect rfc7530.   It wouldn't update rfc750 since
it would say exactly what rfc7530 says now.  Stiill there is a value in
having this all in one place even if the existing treatment of v4.0 I18N
remains as it is until an eventual rfc7530bis.

Section 1.1. I think this text should drop the use of a single document in
favor of talking about a set of authorative correct specifications. I think
you could consider the language Adam Roach uses in
https://datatracker.ietf.org/doc/draft-roach-bis-documents/ to motivate
this approach.

OK.

>    1. Section 1.1:
>    Note the two “of” in first sentence.
>
>
Will fix.

Section 1.1: I think the first paragraphs should be a bit more explicit
about that this is a limited scope update. I would suggest the following:

The revised description of the NFS version 4 minor version 1 (NFSv4.1)
protocol presented in this update is necessary to enable full use of
trunking in connection with multi-server namespace features and to enable
the use of transparent state migration in connection with NFSv4.1.  This
document is in the form of a updated description of the NFS 4.1 protocol
previously defined in [RFC5661]. RFC5661 is obsoleted by this document.
However, the update has a limited and focused scope on enabling full use of
trunking, the need for these changes are discussed in Appendix A. Appendix
B described the specific changes made to arrive at the current text.

>    1.
>    This limited scope update is applied on the main NFSv4.1 RFC is
>    intending to provide an authorative complete specification, the motivation
>    for this is discussed in [I.D-roach-bis-documents], addressing the issues
>    within the scope of the update. However, it will not address issues that
>    are known but outside of this limited scope as could expected by a full
>    update of the protocol. Below are some areas which are known to need
>    addressing in a future update of the protocol.
>
>
Like this text.  will incorporate.

Section 22: IANA Consideration

OK.

I  intend to have these updates available some time next week.   Are you
expecting a -02 that includes the changes to address your review together
with the work previously posted to the list to address the oe errata
relevan to rfc5661sesqui, i.e. 2006?.