Re: [nfsv4] Update on documents related to rfc5661bis effort.

[Chuck Lever III <[e-mail]>]

On Oct 11, 2022, at 4:59 PM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:

As before. My remarks are made as editor of the documents in question and as a wg member.

On Tue, Oct 11, 2022 at 9:29 AM Chuck Lever III <[e-mail]<mailto:[e-mail]>> wrote:


On Oct 9, 2022, at 10:06 AM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:

As before, my remarks are made as the editor of draft-{ietf,dnoveck}-nfsv4-{internationaization,security,rfc5661bis,rfc5662bis} and a wg member and not as wg co-chair.

On Sat, Oct 8, 2022 at 11:23 AM Chuck Lever III <[e-mail]<mailto:[e-mail]>> wrote:

On Oct 8, 2022, at 5:54 AM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:

On Wed, Oct 5, 2022, 10:44 AM Chuck Lever III <[e-mail]<mailto:[e-mail]>> wrote:

Thanks for posting your plan!

We already have three WG documents (not counting the RPC/RDMA v2 documents that are to expire), at least two of which might require significant external review. In years past, we had a large body of folks who could help out. But these days, and considering the total number of pages involved, does the WG have enough review and document stewardship resources to proceed with all of these in parallel?

Rfc5661bis has already been put off far too long, so I  really can't see us doing these seriatim.  By the time we get to the bis, it will be difficult to remember the issues, even though they will still need to be dealt with. Sigh!

Note that it is already almost 13 years since rfc5661 was published and that it is clearly deficient in a  number of major areas.  That is why I have devoted a lot of my time to this effort.  I had been assuming that the working group in general was in a position to do its part.  If it isn't, then the working group is in the position of doing extensions to v4.1 without a good description of v4.1, the previous approval of rfc5661 and rfc8881 as a Proposed Standards notwithstanding.

You might misunderstand my concern.

I might or might not understand your concern.  You appear to want to give the three documents you refer to priority over my three documents related to the bis effort.  Since you do not provde any reason for this stance, it is quite hard to understand your position.

I want to give the three existing WG documents (including i18n) a fair shot at available resources because they are already adopted. The other bis documents have not yet been adopted, and I fear that once they are, they will consume all remaining oxygen, leaving nothing left for completing documents that were adopted before them.

It is true that progress on pnfs-nvme and delstid has been slow but I feel that is primarily because of the details of those specific efforts and not a generalized shortage of resources that might be affected by work on the bis documents going forward.

Again, I'm not talking about the past. I'm looking at what review and stewardship resources are available right now and going forward. So I don't regard the below bullets as relevant to this discussion.


  *    pnfs-nvme has gone way beyond its original milestone and the adopted draft is an informational document while the milestone says "as a Proposed Standard".   There is no indication that this delay is due to  ongoing work on the bis documents which have been making progress independently.
  *   delstid, while adopted, needs significant work to make it ready for IESG submission.   That is primarily because it was left expired without any work for several years.  The bis documents have had no no effect on that and ironically, the only serious review of the document was by me, despite the fact I was working on the bis.

 These document have had a fair shot of available resources and don't see that changing.


The minutiae around adoption of the i18n document were not especially transparent to the WG diaspora.

I'm not sure what you mean or even who the "WG diaspora" might be.   In any case, document adoption was discussed on the mailing list, although I am not aware of any "minutiae" being discussed in connection with wg adoption.

Decisions about chair recusal and the selection of a document steward were announced to the mailing list. I don't recall seeing any discussion of those issues in advance of that announcement. I can only assume that a conversation took place privately, from which those choices arose. My simple request is that such conversations be held in the open instead.


The security document appears to contain new protocol in it,

I don't know what you mean.   rfc5662bis does not change the OTW XDR and any new protocol is discussed as possible future protocol extensions.   Also, note that I originally added discussion of protocol security extensions in response to your request.

but because this effort is officially a bis effort, it should be constrained to documenting existing implementations

I don't agree.   In any case, this is kind of late to shift things to such a restricted model.

I don't believe this is a shift. The generic bis process has always been about dealing with errata and addressing issues with specification language. Innovating as-yet unimplemented protocol would be considered only as a very last resort. I'm not seeking a change in that mission.


It has always been clear that providing a threat analysis  and adapting recommendations to reflect the need for encryption and the security problems with AUTH_SYS were an integral part of this work.

A threat analysis does not need to include new protocol, and any proper discussion of problems with AUTH_SYS really ought to be done without reference to specific encryption mechanisms, since deployments actually have more than one available: Kerberos, TLS, VPN solutions such as wireguard or IPsec, and physically private networks are some examples.

Enumerating security issues with AUTH_SYS without addressing them is still pretty useful, as long as the document can honestly state we are working to address those issues.


I don't see how we can do a security document for NFSv4 that does not do that.   We also have to provide a security considerations section with a real threat analysis.  I don't think we want one that just documents the fact that nfsv4 security is a not in a good state, leading readers to conclude it should not be used.

I'm requesting that the new protocol elements be moved out of this document before it is adopted.

Please be more specifIc about what you mean by "new protocol elements."  It doesn't make sense for me to guess what might strike you that way.

I've already been explicit in this forum about the two areas that are objectionable, but I will summarize them again, lest we continue to be distracted by an undue obsession with my secondary concerns about WG resources.

1. The discussion about the treatment of ACLs needs to carefully describe what existing implementations do. A bis should not introduce new requirements in this area, and to date I have not heard a convincing argument that the security document needs to do so (even though, if I recall correctly, it currently does). I believe it would be irresponsible of the WG to adopt a document that intends to impose new requirements in this area without the agreement of vendors/implementors, as implementation adoption of these new requirements would be unlikely.

2. The originally proposed set of changes to SECINFO included new enumerated values (if I recall correctly) that could be included in the returned flavor list. Based on the tepid feedback we've already received in this area, my conclusion is that this specific area needs to be done with prototypes in collaboration with implementors, which would be a significant impedance to getting the other spec issues addressed in a timely manner. And, again, without consensus amongst implementors/vendors that SECINFO even has a hole that needs to be closed, it's not likely that this new protocol mechanism will be adopted.

My view is that a bis process becomes increasingly unfeasible as the scope of work wanders away from just addressing errata and concerns about spec language. Innovating new protocol needs to be done in concert with implementors, and it really should be done outside of efforts to correct spec errors.

Yes, we have been loose about that in the past, but that has been perhaps to the detriment of the NFS protocol.


I'm not certain why WG adoption is necessary in order to make progress.

It is not, but to make progress while the documents are still at the I-D stage, wg members will have to agree to comment on the draft and help to resolve the issues layed out in Appendix B of security.   So far that hasn't happened and if it doesn't happen now there will not be much progress. 😞

IMO you as the editor of the security document need to organize and drive that conversation. You can't reasonably expect it to arise organically from day-to-day conversation.

--
Chuck Lever