Skip to main content

NFS Version 4.1 Update for Multi-Server Namespace
draft-ietf-nfsv4-mv1-msns-update-04

Discuss


Yes

(Spencer Dawkins)

No Objection

(Deborah Brungard)

Abstain


No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Benjamin Kaduk Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2019-03-05) Sent
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.
Spencer Dawkins Former IESG member
Yes
Yes () Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2019-03-06) Not sent
I am borderline between Abstain and No Objections on usefulness of this document as a set of patches to another RFC.
Deborah Brungard Former IESG member
No Objection
No Objection () Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-03-07) Sent
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.
Adam Roach Former IESG member
Abstain
Abstain (2019-03-06) Sent
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.
Alissa Cooper Former IESG member
Abstain
Abstain (2019-03-06) Sent
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.
Alvaro Retana Former IESG member
Abstain
Abstain (2019-03-06) Sent
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
Ben Campbell Former IESG member
Abstain
Abstain (2019-03-05) Sent
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.
Eric Rescorla Former IESG member
Abstain
Abstain (2019-03-07) Sent
I concur with my colleagues that a 100 page document consisting of diffs is not really something we can expect people to process
Suresh Krishnan Former IESG member
Abstain
Abstain (2019-03-07) Sent
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.
Terry Manderson Former IESG member
Abstain
Abstain (2019-03-07) Sent
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.