Subject: [nfsv4] disposition of draft-ietf-nfsv4-rfc5666-implementation-experience

From: Chuck Lever <[email-masked]>
Date: Thu, 8 Sep 2016 11:51:00 -0400

Hi-

The original purpose of draft-ietf-nfsv4-rfc5666-implementation-experience
was two-fold:

 - To act as a problem statement for updating RFC 5666

 - To act as a stop-gap for helping future implementers of RPC-over-RDMA until
an updated RFC 5666 could be published

IMO these two purposes have been fulfilled, now that rfc5666bis has reached
WGLC.

During the March 2016 RDMA design conference call, Bill Simpson asked that
rfc5666-implementation-experience draft be considered to become an RFC. As I
understand it, he felt it contained information not in rfc5666bis that could
be valuable to future implementers, and thus should be made available as an
Informational RFC. There was no objection to publication at that time.

Strictly speaking, there's no cost to the WG for it, but publishing an RFC is
not free. I'm looking at my own workload and the workload of WG chair and the
IESG and wondering if there's another way to retain the information in this
document without the cost of ratification and publication.

It does not specify a protocol or even conventions that need consensus; all
that is already done in rfc5666bis. If it isn't, rfc5666bis should be changed
to include such items.

I think there is unlikely to be much change to the content of the
implementation experience document as it moves through IESG review and beyond.

If left to expire, this document will continue to exist in the expired I-D
archive. I don't see that publication lends increased value, except perhaps
by making its content somewhat easier to find. [*]

Lastly, is this a document that is likely to be cited by others, and would it
be of value to other IETF participants? I think its value is largely historical,
with perhaps some value as implementation advice. Very much like other I-Ds in
the archive of expired I-Ds.

Therefore, since it is not already cited by other I-Ds, I propose that this
document be dropped from the three RDMA related documents that finished last
call in June, and allowed to expire.

Comments?

--
Chuck Lever

[*] We have, already, another expired I-D which is part of the canon of
material recommended for RPC-over-RDMA implementers:

  https://tools.ietf.org/html/draft-hilland-rddp-verbs-00

Along with these:

  RFC 1832
  RFC 5040-42
  RFC 5531
  RFC 5666(bis)
  RFC 5667(bis)

There is some overlap between that document and RFCs 5040-42, just as there is
between rfc5666bis and rfc5666-implementation-experience.

Spencer Dawkins suggested creating an nfsv4 wiki where we could cite this kind
of reference material. Is that of interest to anyone?

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 9 Sep 2016 17:14:49 +0000

Chuck,

I support your proposal as stated - let the I-D stand as-is.

Spencer

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of Chuck Lever
Sent: Thursday, September 8, 2016 8:51 AM
To: NFSv4 <[email-masked]>
Subject: [nfsv4] disposition of draft-ietf-nfsv4-rfc5666-implementation-experience

Hi-

 - To act as a stop-gap for helping future implementers of RPC-over-RDMA until an updated RFC 5666 could be published

IMO these two purposes have been fulfilled, now that rfc5666bis has reached WGLC.

During the March 2016 RDMA design conference call, Bill Simpson asked that rfc5666-implementation-experience draft be considered to become an RFC. As I understand it, he felt it contained information not in rfc5666bis that could be valuable to future implementers, and thus should be made available as an Informational RFC. There was no objection to publication at that time.

Strictly speaking, there's no cost to the WG for it, but publishing an RFC is not free. I'm looking at my own workload and the workload of WG chair and the IESG and wondering if there's another way to retain the information in this document without the cost of ratification and publication.

It does not specify a protocol or even conventions that need consensus; all that is already done in rfc5666bis. If it isn't, rfc5666bis should be changed to include such items.

I think there is unlikely to be much change to the content of the implementation experience document as it moves through IESG review and beyond.

If left to expire, this document will continue to exist in the expired I-D archive. I don't see that publication lends increased value, except perhaps by making its content somewhat easier to find. [*]

Lastly, is this a document that is likely to be cited by others, and would it be of value to other IETF participants? I think its value is largely historical, with perhaps some value as implementation advice. Very much like other I-Ds in the archive of expired I-Ds.

Therefore, since it is not already cited by other I-Ds, I propose that this document be dropped from the three RDMA related documents that finished last call in June, and allowed to expire.

Comments?

--
Chuck Lever

[*] We have, already, another expired I-D which is part of the canon of material recommended for RPC-over-RDMA implementers:

  https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-hilland-rddp-verbs-00&data=02%7c01%7csshepler%40microsoft.com%7cd5af168cdf4f4b18677208d3d8008460%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636089469137625631&sdata=IR%2fLFVWsfPqsfZsFdpZVPhmazU7peU8wFitiI5evwsg%3d

Along with these:

  RFC 1832
  RFC 5040-42
  RFC 5531
  RFC 5666(bis)
  RFC 5667(bis)

There is some overlap between that document and RFCs 5040-42, just as there is between rfc5666bis and rfc5666-implementation-experience.

Spencer Dawkins suggested creating an nfsv4 wiki where we could cite this kind of reference material. Is that of interest to anyone?

_______________________________________________
nfsv4 mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fnfsv4&data=02%7c01%7csshepler%40microsoft.com%7cd5af168cdf4f4b18677208d3d8008460%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636089469137625631&sdata=2HChNwS8JNDzEVTlLnjGyzbJ1REYu4SSzKsc92G8mQQ%3d

---

From: Chuck Lever <[email-masked]>
Date: Mon, 26 Sep 2016 08:50:06 -0700

Spencer, I have heard no further objections to this plan,
so let's go with it.

> On Sep 9, 2016, at 10:14 AM, Spencer Shepler <[email-masked]> wrote:
> 
> 
> Chuck,
> 

--
Chuck Lever

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 26 Sep 2016 18:56:39 +0000

Thanks for closing the loop, Chuck.

-----Original Message-----
From: Chuck Lever [mailto:[email-masked]] 
Sent: Monday, September 26, 2016 8:50 AM
To: Spencer Shepler <[email-masked]>
Cc: NFSv4 <[email-masked]>
Subject: Re: [nfsv4] disposition of draft-ietf-nfsv4-rfc5666-implementation-experience

Spencer, I have heard no further objections to this plan, so let's go with it.

> Subject: [nfsv4] disposition of 
> draft-ietf-nfsv4-rfc5666-implementation-experience
> 
> Hi-
> 
> The original purpose of 
> draft-ietf-nfsv4-rfc5666-implementation-experience
> was two-fold:
> 
> - To act as a stop-gap for helping future implementers of 
> RPC-over-RDMA until an updated RFC 5666 could be published
> 
> If left to expire, this document will continue to exist in the expired 
> I-D archive. I don't see that publication lends increased value, 
> except perhaps by making its content somewhat easier to find. [*]
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools
> .ietf.org%2fhtml%2fdraft-hilland-rddp-verbs-00&data=02%7c01%7csshepler
> %40microsoft.com%7cd5af168cdf4f4b18677208d3d8008460%7c72f988bf86f141af
> 91ab2d7cd011db47%7c1%7c0%7c636089469137625631&sdata=IR%2fLFVWsfPqsfZsF
> dpZVPhmazU7peU8wFitiI5evwsg%3d
> 
> Along with these:
> 
>  RFC 1832
>  RFC 5040-42
>  RFC 5531
>  RFC 5666(bis)
>  RFC 5667(bis)
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2fnfsv4&data=02%7c01%7csshepler%40microso
> ft.com%7cd5af168cdf4f4b18677208d3d8008460%7c72f988bf86f141af91ab2d7cd0
> 11db47%7c1%7c0%7c636089469137625631&sdata=2HChNwS8JNDzEVTlLnjGyzbJ1REY
> u4SSzKsc92G8mQQ%3d

--
Chuck Lever