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

[Spencer Shepler <[e-mail]>]

Thanks for closing the loop, Chuck.

-----Original Message-----
From: Chuck Lever [mailto:[e-mail]] 
Sent: Monday, September 26, 2016 8:50 AM
To: Spencer Shepler <[e-mail]>
Cc: NFSv4 <[e-mail]>
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.


> On Sep 9, 2016, at 10:14 AM, Spencer Shepler <[e-mail]> wrote:
> 
> 
> Chuck,
> 
> I support your proposal as stated - let the I-D stand as-is.
> 
> Spencer
> 
> -----Original Message-----
> From: nfsv4 [mailto:[e-mail]] On Behalf Of Chuck Lever
> Sent: Thursday, September 8, 2016 8:51 AM
> To: NFSv4 <[e-mail]>
> 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 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://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)
> 
> 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
> [e-mail]
> 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