Ballot for draft-ietf-nfsv4-mv1-msns-update
Discuss
Yes
No Objection
Abstain
No Record
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
I think this is a useful document to clarify the proper operation of NFS 4.1, and to clarify the distinction between trunking address changes and migration, and intend to change my ballot to Yes once the following issues are resolved. The Security Considerations state or imply in multiple places that the use of RPCSEC_GSS to access a designated server can be used to verify the target name and address resolution, but this only holds when the GSSAPI (and Kerberos) implementation refrains from using insecure DNS to canonicalize the target principal hostname. (Several major ones do not, by default.) It is irresponsible to not note this risk here. Specifically, the following text from Section 1.3 of RFC 4120 is honored more in the breach: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). We are deleting Section 11.7 of 5661, but it talks about encoding "opaque" values conveyed from server to server via client in big-endian order, and don't seem to cover that in this document. Is that problematic? I also have a few other issues/questions that don't quite rise to DISCUSS level, but are still important to address; I tagged those with "IMPORTANT" in the comment section, so they don't get drowned in the nits.
I am borderline between Abstain and No Objections on usefulness of this document as a set of patches to another RFC.
I didn't have the time to review this document in depth but I agree with others that the selected approach is hard to follow. I would have preferred a bis document or a stand-alone document that updates RFC5661 content-wise but does not have a patch-style and therefore can "simply" be consumed in addition to RFC5661.
I agree with Ben's comments that this format is hostile to implementors, and that the community would be far better served by a bis document.
I agree with Ben Campbell and am therefore abstaining. It seems like the proper path to a more broadly usable specification would have been to obsolete RFC 5661 and produce a bis with the changes applied. I don't see an explanation anywhere for why that was not done. The RFC 8174 boilerplate should be used in Section 2. The shepherd write-up notes an issue with "minor copyright dates." The issue is not one of dates but rather about whether the pre-RFC5378 disclaimer is needed or not.
I agree with Ben's opinion. As it is being discussed on the nsfv4 list, there are enough issues and changes to rfc5661 to justify a bis [1], the most significant seems to be what is already included in this document. [1] https://mailarchive.ietf.org/arch/msg/nfsv4/Hj5dTm-qYG3dZFyhy1VBqWv44XA
Thanks for the huge amount of work in this draft, but I cannot recommend publishing it in it's current form. I am balloting "ABSTAIN" rather than "DISCUSS", so that I do not get in the way of publication if the rest of the IESG thinks it's fine as is. I apologize for not doing a more technical review, but I think the structural issues need to be addressed first. I once spent several weeks over a summer in high school applying page updates to a shelf full of US Tax Code binders in a CPAs office. The IRS, (or whoever published the code) would send out boxes of new page-sets, each labeled for which original pages it would replace. When we were done in the CPA office, we had a coherent set of documents, at least to the degree you can apply words like "coherent" to tax codes. This draft does something akin to that, except that we don't end up with a coherent document as a result. If the RFC Editor applied patches from RFCs that "UPDATE" other RFCs to render final text, things would be different. But that doesn't happen with RFCs. That being said, I don't object to RFC updates in general, as long as those updates are simple and fairly self-contained. But this draft is over 100 pages of intricate updates, reorganizations, and explanatory text. This will make life very hard for readers that were not involved in the standards process. I think the right approach for an update of this complexity is to just do a 5661bis draft, and use this one as an input to that. Such a bis draft could be something as simple as applying the changes in this draft (and maybe trunking-update) and publishing the result.
I concur with my colleagues that a 100 page document consisting of diffs is not really something we can expect people to process
Thanks to the authors for doing the hard work in creating this document. I sincerely tried to give this document a proper review but, like my abstaining co-ADs, I gave up along the way. The biggest issues for me were the reorganizations, lack of information about interoperability and backward compatibility with unupdated implementations, code snippet replacements with no apparent change (e.g. section 14.1 replacing 18.35.1, section 14.2 replacing 18.35.2. etc.) and so on. I also think that doing a new version of RFC5661 with the changes applied is the right way to go about this, but I will abstain so that the WG and the responsible AD can make the call.
My review of this document took me some time as I had to do a side my side read with RFC5661. While not normally a bad way to implement 'updates' I found myself lost more times than not. The complexity of the updates in this way loses readability and technical coherence, even though a lot of thought and effort has been invested in this work. I think that the loss of readability and technical coherence should be avoided for many reasons if not based alone on what we currently see in the set of documents which describes DNS. On this document I am balloting ABSTAIN as I feel that there are better ways to handle the depth breadth of this update, however I will not stand in the way of publication.