Subject: [nfsv4] High-priority agenda items for discussion at IETF105.

From: David Noveck <[email-masked]>
Date: Tue, 21 May 2019 13:57:20 -0400

Although we have decided to meet in Montreal, have a (two-hour) session
scheduled, and Chuck and I have sent lists of proposed topics to the group,
we need to get an agenda together for the meeting.   Chuck and I have
discussed what we feel are the high-priority topics for discusion at the
meeting.   This has resulted in the (incomplete) preliminary agenda below.
 I'd like to hear from:

   - Anyone who knows of additional high-priority items to be added the
   list.
   - Anyone who feels that we should *not *be talking about any of the
   items currently on the list

It look like there will be additional time available.   If people have
items to discuss that are not high-priority, they should send messages to
the list and assess interest.   If there are too many to fit, the working
group can express its priorities.  If we still wind up with available time
when IETF105 rolls around, we can open up the meeting for whatever people
would like to bring up.

--------------------------------------------------------------------------------------------------------

*Agenda Bashing -- All -- 5 min.*

*Current updates* *to NFSv4 spec -- D. Noveck -- 20 min.*

This will cover the following documents

   - RFC8587 (*NFS Version 4.0 Trunking Update*): It makes sense to discuss
   this tgether with the document below since the trunking-related updates for
   both NFSv4.0 and NFSv4.1 are pretty much the same, even though one is
   cuurrently an RFC, while the other might not be when we meet.
   - draft-ietf-nfsv4-rfc5661-msns-update (*NFS Version 4.1 Update for
   Multi-Server Namespace*):This covers updates to NFSv4.1 dealing with
   trunking and transparent state migration.  If necessary, there will also be
   an update regarding the state of the approval/publication process.

*Review of Current Working group Milestones -- C Lever -- 20 min.*

This will cover all of our current miilestones that are neither dealt with
in other talks (3 including one already done and two close to being done)
or done but not dealt with in other talks (1).

There are four items that still need to be discussed:

   - Submit final document describing CM private data convention for
   RPC-over-RDMA version 1 (Informational)

This is now a working group document
draft-ietf-nfsv4-rpcrdma-cm-pvt-data (*RDMA
Connection Manager Private Data For RPC-Over-RDMA Version 1*).

   - Submit final document defining RPC-over-RDMA Version 2 (as Proposed
   Standard)

This is now an I-D, draft-cel-nfsv4-rpcrdma-version-two (*RPC-over-RMA
Version Two Protocol*).

   - Submit final document describing use of NVMe in accessing a pNFS SCSI
   Layout (as Proposed Standard)

No current document but still has working group interest. Probably should
not be a milestone. Need a plan to go forward with this.

   - Submit final document describing pNFS RDMA Layout (as Proposed Standard)

No current document but still has working group interest.   Needs to
consider whether it is still appropriate as a milestone.   Need a plan
to make progress on this.

*Review of Current Security Work -- C.Lever -- 15 min.*

This will be primarily focused on draft-etf-nfsv4-rpc-tls (*Remote
Procedure Call Encryption by Deafault)* but we also want to discuss the
potential need for other documents such as an NFSv4-focused document.

*Moving Forward on Integrity Measurement Draft -- 10 min.*

Time for discussion of the future of
draft-ietf-nfsv4-integrity-measurement (*Integrity Measurement for Network
File System version 4*) and possible objection/issues with that draft.

*Proposed Plans for rfc5661bis -- D. Noveck -- 15 min.*

Will discuss updates that need to be done to provide a reasonably current
description of NFSv4.1.   The assumption is that the bis RFC document will
be based  on draft-ietf-nfsv4-rfc5661-msns-update (*NFS Version 4.1 Update
for Multi-Server Namespace*) coverted, as the IESG appears to want, into a
bis-like format but that the following additional changes would need to be
added:

   - Updates to reflect the changes Tom made to pNFS mapping type
   requirements in RFC8434.
   - Changes to avoid the NFSv4.1 specification contradicting RFC8178.
   - A new internationalization section modeled on that in RFC7530
   - A new Security Considerations section that meets the requirements of
   RFC3552 and reflect the changes/advances made my the security work now
   underway.
   - Current erratta.
   - Anything else people think needs to be fixed in the NFSv4.1
   specification.

We can also consider alternate plans to provide more current NFSv4.1
specification documents.
_____________________________________________________________________________

I'd like to mention that, for those unable to be in Montreal on the week of
7/20, remote participation will be available, even for people who want to
present a talk.   Time zones can be a drag, but it is well worth
considering remote presentation if you have something you think the working
group needs to hear

---

From: Joe Breher <[email-masked]>
Date: Tue, 21 May 2019 13:13:58 -0600

I am piggybacking on this in order to provide the following notice of a tangentially-related development.

INCITS T10 has balloted to forward INCITS 551-201x - Information technology - SCSI RDMA Protocol - 2 (SRP - 2) for further processing towards public review. This milestone is an indication that the T10 committee believes the technical content of this draft standard to be complete and correct. Anyone with an interest in this draft standard may want to be alert for an announcement of the public review period opening by ANSI.

The latest SRP-2 draft standard srp2r06.pdf is available on the t10.org <http://t10.org/> website.

That is all.

Joe Breher
Manager,
lingua data, LLC
Technical Editor, INCITS T10 SRP-2
(478) 2-Breher
(478) 227-3437

> On May 21, 2019, at 11:57 AM, David Noveck <[email-masked]> wrote:
> 
> Although we have decided to meet in Montreal, have a (two-hour) session scheduled, and Chuck and I have sent lists of proposed topics to the group, we need to get an agenda together for the meeting.   Chuck and I have discussed what we feel are the high-priority topics for discusion at the meeting.   This has resulted in the (incomplete) preliminary agenda below.   I'd like to hear from:
> Anyone who knows of additional high-priority items to be added the list.
> Anyone who feels that we should not be talking about any of the items currently on the list
> It look like there will be additional time available.   If people have items to discuss that are not high-priority, they should send messages to the list and assess interest.   If there are too many to fit, the working group can express its priorities.  If we still wind up with available time when IETF105 rolls around, we can open up the meeting for whatever people would like to bring up.
> 
> Agenda Bashing -- All -- 5 min.
> 
> Current updates to NFSv4 spec -- D. Noveck -- 20 min.
> 
> RFC8587 (NFS Version 4.0 Trunking Update): It makes sense to discuss this tgether with the document below since the trunking-related updates for both NFSv4.0 and NFSv4.1 are pretty much the same, even though one is cuurrently an RFC, while the other might not be when we meet.
> draft-ietf-nfsv4-rfc5661-msns-update (NFS Version 4.1 Update for Multi-Server Namespace):This covers updates to NFSv4.1 dealing with trunking and transparent state migration.  If necessary, there will also be an update regarding the state of the approval/publication process.
> Review of Current Working group Milestones -- C Lever -- 20 min.
> 
> This will cover all of our current miilestones that are neither dealt with in other talks (3 including one already done and two close to being done) or done but not dealt with in other talks (1).
> 
> Submit final document describing CM private data convention for RPC-over-RDMA version 1 (Informational)
> This is now a working group document draft-ietf-nfsv4-rpcrdma-cm-pvt-data (RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1).
> Submit final document defining RPC-over-RDMA Version 2 (as Proposed Standard)
> This is now an I-D, draft-cel-nfsv4-rpcrdma-version-two (RPC-over-RMA Version Two Protocol).
> Submit final document describing use of NVMe in accessing a pNFS SCSI Layout (as Proposed Standard)
> No current document but still has working group interest.   Probably should not be a milestone.  Need a plan to go forward with this.
> Submit final document describing pNFS RDMA Layout (as Proposed Standard)
> No current document but still has working group interest.   Needs to consider whether it is still appropriate as a milestone.   Need a plan to make progress on this.
> Review of Current Security Work -- C.Lever -- 15 min.
> 
> This will be primarily focused on draft-etf-nfsv4-rpc-tls (Remote Procedure Call Encryption by Deafault) but we also want to discuss the potential need for other documents such as an NFSv4-focused document.
> 
> Moving Forward on Integrity Measurement Draft -- 10 min.
> 
> Time for discussion of the future of  draft-ietf-nfsv4-integrity-measurement (Integrity Measurement for Network File System version 4) and possible objection/issues with that draft.
> 
> Proposed Plans for rfc5661bis -- D. Noveck -- 15 min.
> 
> Will discuss updates that need to be done to provide a reasonably current description of NFSv4.1.   The assumption is that the bis RFC document will be based  on draft-ietf-nfsv4-rfc5661-msns-update (NFS Version 4.1 Update for Multi-Server Namespace) coverted, as the IESG appears to want, into a bis-like format but that the following additional changes would need to be added:
> Updates to reflect the changes Tom made to pNFS mapping type requirements in RFC8434.
> Changes to avoid the NFSv4.1 specification contradicting RFC8178.
> A new internationalization section modeled on that in RFC7530
> A new Security Considerations section that meets the requirements of RFC3552 and reflect the changes/advances made my the security work now underway. 
> Current erratta.
> Anything else people think needs to be fixed in the NFSv4.1 specification.
> We can also consider alternate plans to provide more current NFSv4.1 specification documents..
> I'd like to mention that, for those unable to be in Montreal on the week of 7/20, remote participation will be available, even for people who want to present a talk.   Time zones can be a drag, but it is well worth considering remote presentation if you have something you think the working group needs to hear
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4