Chuck Lever | 20 Jul 18:03 2016
Picon

Review of draft-dnoveck-nfsv4-rpcrdma-xcharext-00

This is a long-form full document review of draft-dnoveck-nfsv4-rpcrdma-xcharext-00. Please feel free
to respond with clarifying questions or further discussion where needed, and no response is necessary
where the author(s) agree to a suggestion or plan to ignore it.

Comments applying to the whole document:

Subsequent extensions might each define one or more new characteristics. Since the extension specified
in this document is a (necessary) extensibility enabler, should we consider merging it into the base
RPC-over-RDMA Version Two protocol?

Two of the three initially specified transport characteristics need further technical discussion
outside the scope of the review of this document.

*** Abstract

Editorial:

IMO it's safe to assume in the abstract that RPC-over-RDMA Version Two will have a mechanism that permits
extension of the base RPC-over-RDMA protocol. Explaining that in this document's abstract seems
unnecessary, and the use of subjunctive mood and future tense dulls the impact of both the abstract and the
introduction section. Also, the term RPC-over-RDMA is preferred over the term RPC/RDMA.

I suggest tightening the text as follows:

OLD
It is expected that the RPC-over-RDMA transport will, at some point, allow protocol extensions to be
defined. This would provide for the specification of OPTIONAL features, allowing participants who
implement the OPTIONAL features, to cooperate as specified by that    extension, while still
interoperating with participants who do not support that extension.

(Continue reading)

spencer shepler | 19 Jul 17:41 2016
Picon

IETF96 presentations for NFSv4


I have posted all presentation material to the proceedings site. 

Presenters - if you see something missing/wrong, please send me email.

Will need minutes from the meeting in case someone took notes.

All IETF meetings' recordings are here:


The NFSv4 meeting can be viewed here:


Spencer

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Mike Kupfer | 15 Jul 23:44 2016
Picon

draft-ietf-nfsv4-versioning-04, Section 4

As I continue the dribbling out of feedback...

- Section 4.1.1 ("XDR Extension in General") refers to "operation
  codes"; I think it would be better to speak in terms of "procedures"
  here.  The distinction is even more important in Section 4.1.2 (first
  bullet in that section) and Section 4.1.3 (list of prohibited
  changes).

- Section 4.2, first bullet, "RPC XDR decode error.  reports": change
  the period to a comma.

- page 14:

  * The protocol element is not known in the current variant of minor
    version.

  Change "of minor" to "of the minor".

- page 14, 2nd-to-last paragraph, "protocol elements, will": omit
  comma.

- page 14, last paragraph: maybe add a cross-reference to Section 6.6.

- Section 4.4: "version" is used in several places where "variant"
  would be more precise

- Section 4.4, first paragraph, "client and server versions have XDR
  definitions": change "have" to "may have"

- Section 4.4.1, first paragraph, "use of XDR extension paradigm":
  change "of XDR" to "of the XDR"

- Section 4.4.1, first bullet, "base variant of particular minor
  version": change "of particular" to "of a particular"

- Page 16, "For many minor versions, all existing protocol elements,
  are": delete the comma after "elements".

- Page 16, second-to-last bullet in Section 4.4.1 ("If the responder
  is aware of..."): end with a period (make a complete sentence).

- Section 4.4.2: this section is worded in terms of the client
  determining what features the server supports.  Please add a
  cross-reference to Section 7.3.2, since that section discusses
  callback extensions.

regards,
mike

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

RFC Errata System | 15 Jul 11:05 2016

[Technical Errata Reported] RFC7530 (4742)

The following errata report has been submitted for RFC7530,
"Network File System (NFS) Version 4 Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7530&eid=4742

--------------------------------------
Type: Technical
Reported by: Manju Karthik <manjuk <at> netapp.com>

Section: section-6.2.

Original Text
-------------
https://tools.ietf.org/html/rfc7530#section-6.2.1

   The client can use the OPEN or ACCESS
   operations to check access without modifying or reading data or
   metadata.

Corrected Text
--------------
   The client can use the OPEN or ACCESS
   operations to check access without modifying or reading data.

Notes
-----
Whenever client does OPEN/ACCESS call, there is an inadvertent change in the Last Access time of the file.
Hence we think that the Metadata is modified due to OPEN/ACCESS call.  Hence the Suggestion is to change the
text as above.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7530 (draft-ietf-nfsv4-rfc3530bis-35)
--------------------------------------
Title               : Network File System (NFS) Version 4 Protocol
Publication Date    : March 2015
Author(s)           : T. Haynes, Ed., D. Noveck, Ed.
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

spencer.shepler | 14 Jul 19:52 2016
Picon

Remote presentations for Berlin / IETF96

<resend in case Microsoft email doesn’t come through>

 

The IETF uses Meetecho for remote presentations.  I have submitted a request for Dave’s presentation.

 

Are there others that will be doing remote presentations as well? The deadline for submitted requests is July 15th.

 

Spencer

 

 

Sent from Mail for Windows 10

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Spencer Shepler | 14 Jul 19:50 2016
Picon

Remote presentations for Berlin / IETF96

 

The IETF uses Meetecho for remote presentations.  I have submitted a request for Dave’s presentation.

 

Are there others that will be doing remote presentations as well? The deadline for submitted requests is July 15th.

 

Spencer

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
David Noveck | 14 Jul 11:50 2016
Picon

Slides for IETF96

Attached are two slide sets  for talks I'll be giving at the nfsv4wg meeting at IETF96.  

Because of travel budget issues, I will not be in Berlin, and will be giving these talks
remotely.  I'm assuming that information on call-in arrangements will be made available 
between now and the meeting.  If not, I can be reached at +1 781-572-8038
Attachment (IETF96 Extension.pptx): application/vnd.openxmlformats-officedocument.presentationml.presentation, 87 KiB
Attachment (IETF96 RpcRdma.pptx): application/vnd.openxmlformats-officedocument.presentationml.presentation, 101 KiB
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Black, David | 10 Jul 21:09 2016

NVMe and pNFS SCSI layout - two comments

Two quick comments: 

(1) Section 2.1 on Volume Identification could use some tightening.
As a straw proposal I'd suggest (on the NVMe side):
	- MUST use one of EUI64 or NGUID identification
	- SHOULD use NGUID identification, as it's a larger ID.
	- MUST NOT use serial number for identification with the pNFS SCSI layout.

(2)  Should add a discussion on registering with all controllers as an analog to registering all SCSI I_T
Nexuses - the NVMe Host Identifier simplifies this by comparison to SCSI, but this is an area where
relying strictly on SCSI translation may not suffice.

Thanks, --David

> -----Original Message-----
> From: nfsv4 [mailto:nfsv4-bounces <at> ietf.org] On Behalf Of Christoph Hellwig
> Sent: Friday, July 08, 2016 9:19 AM
> To: Chuck Lever; nfsv4 <at> ietf.org
> Subject: [nfsv4] [internet-drafts <at> ietf.org: New Version Notification for draft-
> hellwig-nfsv4-scsi-layout-nvme-00.txt]
> 
> 
> As promised to Chuck and a few others a while ago here is the
> draft on how to use the SCSI to NVMe mapping for using the
> SCSI layout with NVMe storage devices.
> 
> ----- Forwarded message from internet-drafts <at> ietf.org -----
> 
> Date: Fri, 08 Jul 2016 06:16:54 -0700
> From: internet-drafts <at> ietf.org
> Subject: New Version Notification for
> 	draft-hellwig-nfsv4-scsi-layout-nvme-00.txt
> To: Christoph Hellwig <hch <at> lst.de>
> 
> 
> A new version of I-D, draft-hellwig-nfsv4-scsi-layout-nvme-00.txt
> has been successfully submitted by Christoph Hellwig and posted to the
> IETF repository.
> 
> Name:		draft-hellwig-nfsv4-scsi-layout-nvme
> Revision:	00
> Title:		Using the Parallel NFS (pNFS) SCSI Layout with NVMe
> Document date:	2016-07-08
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-hellwig-nfsv4-scsi-layout-
> nvme-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hellwig-nfsv4-scsi-layout-
> nvme/
> Htmlized:       https://tools.ietf.org/html/draft-hellwig-nfsv4-scsi-layout-nvme-00
> 
> 
> Abstract:
>    This document explains how to use the Parallel Network File System
>    (pNFS) SCSI Layout Type with transports using the NVMe or NVMe over
>    Fabrics protocol.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Christoph Hellwig | 8 Jul 15:18 2016
Picon

[internet-drafts <at> ietf.org: New Version Notification for draft-hellwig-nfsv4-scsi-layout-nvme-00.txt]


As promised to Chuck and a few others a while ago here is the
draft on how to use the SCSI to NVMe mapping for using the
SCSI layout with NVMe storage devices.

----- Forwarded message from internet-drafts <at> ietf.org -----

Date: Fri, 08 Jul 2016 06:16:54 -0700
From: internet-drafts <at> ietf.org
Subject: New Version Notification for
	draft-hellwig-nfsv4-scsi-layout-nvme-00.txt
To: Christoph Hellwig <hch <at> lst.de>

A new version of I-D, draft-hellwig-nfsv4-scsi-layout-nvme-00.txt
has been successfully submitted by Christoph Hellwig and posted to the
IETF repository.

Name:		draft-hellwig-nfsv4-scsi-layout-nvme
Revision:	00
Title:		Using the Parallel NFS (pNFS) SCSI Layout with NVMe
Document date:	2016-07-08
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-hellwig-nfsv4-scsi-layout-nvme-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hellwig-nfsv4-scsi-layout-nvme/
Htmlized:       https://tools.ietf.org/html/draft-hellwig-nfsv4-scsi-layout-nvme-00

Abstract:
   This document explains how to use the Parallel Network File System
   (pNFS) SCSI Layout Type with transports using the NVMe or NVMe over
   Fabrics protocol.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

David Noveck | 2 Jul 12:04 2016
Picon

Lost (?) email about draft-ietf-nfsv4-flex-files

On May 21, I sent out a review of draft-ietf-nfsv4-flex-files-08.  In order to avoid running afoul of size restrictions on the working group  list, I broke it up into three messages.  These were sent to Tom, Benny and the working group list.

Given that I haven't heard any response, I investigated and found that these, for some reason, didn't make it to the working group list.  At least, they are not on the list archive.

First of ll, I'd like to ask Tom and Benny whether they received these.

Secondly, I'd like to warn people that the mailing list (or maybe it is gmail) is not very reliable and if you send something to the working group list, you might want to check whether it actually got there.

Third, if people do want a copy of these let me know.  I'm going to resend to the working group list but I don't have any confidence that it will work.

This document has been in working group last call for over ten months now.  Part of the reason may be lost/unreliable email.

 
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Mike Kupfer | 29 Jun 23:47 2016
Picon

draft-ietf-nfsv4-versioning-04, Sections 2 and 3

* Section 2

- The term "extensible minor version" is used in several places in the
  spec but I didn't see a definition anywhere.  The main thing I'd
  like to see clarified is that a minor version is extensible because
  the working group says it's extensible, as opposed to being
  something that is derived from the technical details of the version.
  I'd also include a cross-reference to Section 7.4.

- page 5, last paragraph

    In this document, the word "feature" is used , except in the case of

  Delete the extra space before the comma.

- page 5, last paragraph (spilling onto page 6): the last two
  sentences (both starting with "See Section 6") are a jumble.

- page 9, paragraph starting with "Each version variant", sentence
  starting with "For example": change "refer the" to "refer to the"

* Section 3

- The last sentence in the section would be clearer if broken in two:

    Future minor version specification documents should avoid
    specifying minor versioning rules.  Instead, they should reference
    this document in connection with rules for NFSv4 version
    management.

mike

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4


Gmane