Subject: [nfsv4] FW: Gen-ART review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08

From: <[email-masked]>
Date: Fri, 23 Sep 2011 15:32:51 -0400

-----Original Message-----
From: Black, David 
Sent: Friday, September 23, 2011 3:20 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; ietf
Cc: Black, David; [email-masked]; Brian Pawlowski; Spencer Shepler; David Harrington
Subject: Gen-ART review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08
Reviewer: David L. Black
Review Date: September 23, 2011
IETF LC End Date: September 23, 2011

Summary: This draft is on the right track but has open issues, described in the review.

This draft specifies the use of DNS to locate the root of a federated filesystem namespace
based on the fs_locations functionality in NFSv4.

I have two significant open issues:

[1] There has been an extensive Last Call discussion of this draft, focusing on the use
of a composite two-component service name in DNS SRV records, and the apparent
incompatibility of that format with RFC 2782.  This discussion has surfaced a proposed
resolution in the form of  unitary single-level service name specified without a port
number.  It is *vital* that this proposed resolution be reviewed by DNS experts (probably
the DNS directorate) for consistency with DNS as currently specified and deployed.
Another IETF Last Call may be appropriate, as this change has a significant impact on
this draft, involving a serious rewrite of the portion of Section 4.2 that discusses the
possible use of more than two components in a service name and presents a three-component
example.

[2] While NFSv4.1 (RFC 5661) is restricted to TCP, this draft also references NFSv4.0
(RFC 3530) as applicable, and the latter is defined over both UDP and TCP.  Unfortunately,
this draft is written as if TCP is the only transport protocol for NFS - that's not the
case for NFSv4.0, so either this draft needs to say something about use with NFSv4.0 over
UDP, or needs to explicitly prohibit use of this DNS SRV record with NFS over UDP.  If
the former approach is pursued, RFC 5405 on Unicast UDP Usage Guidelines for Application
Designers is an important consideration in writing that text and RFC 5405 should be
added as an informative reference.

idnits 2.12.12 ran clean.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 23 Sep 2011 13:11:03 -0700

On Sep 23, 2011, at 12:32 PM, <[email-masked]> <[email-masked]> wrote:

> [2] While NFSv4.1 (RFC 5661) is restricted to TCP,

No, it is not:

Section 2.9.1 states

   It is permissible for a connectionless transport to be used under
   NFSv4.1; however, reliable and in-order delivery of data combined
   with congestion control by the connectionless transport is REQUIRED.
   As a consequence, UDP by itself MUST NOT be used as an NFSv4.1
   transport.  NFSv4.1 assumes that a client transport address and
   server transport address used to send data over a transport together
   constitute a connection, even if the underlying transport eschews the
   concept of a connection.

> this draft also references NFSv4.0
> (RFC 3530) as applicable, and the latter is defined over both UDP and TCP.

Can you point out an implementation that allows UDP traffic?

The relevant section of the 3530bis (which was not modified in this
regard from RFC 3530) is:

3.1.  Ports and Transports

   Historically, NFSv2 and NFSv3 servers have resided on port 2049.  The
   registered port 2049 [18] for the NFS protocol SHOULD be the default
   configuration.  Using the registered port for NFS services means the
   NFS client will not need to use the RPC binding protocols as
   described in [16]; this will allow NFS to transit firewalls.

   Where an NFSv4 implementation supports operation over the IP network
   protocol, the supported transports between NFS and IP MUST be among
   the IETF-approved congestion control transport protocols, which
   include TCP and SCTP.  To enhance the possibilities for
   interoperability, an NFSv4 implementation MUST support operation over
   the TCP transport protocol, at least until such time as a standards
   track RFC revises this requirement to use a different IETF-approved
   congestion control transport protocol.

   If TCP is used as the transport, the client and server SHOULD use
   persistent connections.  This will prevent the weakening of TCP's
   congestion control via short lived connections and will improve
   performance for the WAN environment by eliminating the need for SYN
   handshakes.

I do not believe UDP is an IETF-approved congestion control transport.

The only mention of UDP in the draft is in the explanation of netids.

In other words, both NFSv4.0 and NFSv4.1 allow for the use of UDP if
and only if it provides congestion control. While several prototypes
allowed for UDP, I don't know of any shipping code which allows for
UDP.

>  Unfortunately,
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Fri, 23 Sep 2011 16:16:24 -0400

Tom,

Without getting into details, the underlying problem is:

> > UDP, or needs to explicitly prohibit use of this DNS SRV record with NFS over UDP.

It sounds like you're advocating the later choice (which would be simpler and fine with
me).  The absence of UDP support in this draft needs to be explained, as the draft is
currently silent on this topic.

Thanks,
--David

> From: Thomas Haynes [mailto:[email-masked]]
> Sent: Friday, September 23, 2011 4:11 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [nfsv4] FW: Gen-ART review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08
> 
> 
> > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 23 Sep 2011 20:29:18 +0000

You are correct, David.  The FedFS I-D needs to be clear about
the reason for the lack of UDP transport results in the DNS SRV
record.

Spencer

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, September 23, 2011 1:16 PM
> To: [email-masked]
> Cc: [email-masked]
> > > this draft is written as if TCP is the only transport protocol for
> > > NFS - that's not the case for NFSv4.0, so either this draft needs to
> > > say something about use with NFSv4.0 over UDP, or needs to explicitly
> prohibit use of this DNS SRV record with NFS over UDP.
> 
> It sounds like you're advocating the later choice (which would be simpler
> and fine with me).  The absence of UDP support in this draft needs to be
> explained, as the draft is currently silent on this topic.
> 
> Thanks,
> --David
> 
> 
> > Subject: Re: [nfsv4] FW: Gen-ART review of
> > draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08
> >
> >
> > > Subject: Gen-ART review of
> > > draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08
> > >
> > > This draft specifies the use of DNS to locate the root of a
> > > federated filesystem namespace based on the fs_locations functionality
> in NFSv4.
> > >
> > > [1] There has been an extensive Last Call discussion of this draft,
> > > focusing on the use of a composite two-component service name in DNS
> > > SRV records, and the apparent incompatibility of that format with
> > > RFC 2782.  This discussion has surfaced a proposed resolution in the
> > > form of  unitary single-level service name specified without a port
> > > number.  It is *vital* that this proposed resolution be reviewed by
> DNS experts (probably the DNS directorate) for consistency with DNS as
> currently specified and deployed.
> > > Another IETF Last Call may be appropriate, as this change has a
> > > significant impact on this draft, involving a serious rewrite of the
> > > portion of Section 4.2 that discusses the possible use of more than
> > > two components in a service name and presents a three-component
> example.
> > >
> > > this draft is written as if TCP is the only transport protocol for
> > > NFS - that's not the case for NFSv4.0, so either this draft needs to
> > > say something about use with NFSv4.0 over UDP, or needs to
> > > explicitly prohibit use of this DNS SRV record with NFS over UDP.
> > > If the former approach is pursued, RFC 5405 on Unicast UDP Usage
> > > Guidelines for Application Designers is an important consideration in
> writing that text and RFC 5405 should be added as an informative
> reference.
> > >
> > > David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > > St., Hopkinton, MA  01748

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 23 Sep 2011 14:38:39 -0700

I agree there is a problem with the I-D. I disagree with the solution to
which we appear to reaching consensus.

NFSv4 is a transport-protocol agnostic file-access-protocol, regardless of
minor version. IESG has limited the set transport-protocols for NFSv4 to
those that manage congestion well, where "well" is subjective to IESG.

draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08 should be written in a
manner that is agnostic about the transport used by the NFSv4 service.

Someday we might publish an RFC that explains how ONC RPC for DCCP and/or
SCTP which are reasonable transports for NFSv4. This RFC would essentially
update the IANA netid registry which we established during the NFSv4.1 RFC
process.  W

We would not need to publish an update to the NFSv4.0, NFSv4.1, and
NFSv4.2 to do so. We should not have to publish an update to the RFC that
draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08 will become.

>> > > (RFC 3530) as applicable, and the latter is defined over both UDP
>> and
>> TCP.

As the co-author RFC 3530, I disagree that NFSv4.0 is defined over UDP.

It most certainly is not.

RFC 3530 mentions just TCP and SCTP as candidate transports.

It also defines netids for TCP/IPv4, UDP/IPv4, TCP/IPv6, and UDP/IPv6.

The resulting intersection of supported transports are: TCP/IPv4 and
TCP/IPv6.

Those are the only two transports currently authorized by IESG for NFSv4.
I agree that RFC 3530 could have made this clearer, and I expect the
RFC3530bis document to clarify it.

Any NFSv4 client that attempts UDP to my server gets rejected, and the
customer gets a message informing him that his client is in violation of
the standard. It's like running DC current in a building wired for AC.

On Fri, September 23, 2011 1:29 pm, Spencer Shepler wrote:
>> explicitly
>> > > Please resolve these comments along with any other Last Call
>> comments
>> you may receive.
>> > >
>> > > (RFC 3530) as applicable, and the latter is defined over both UDP
>> and
>> TCP.
>> >
>> >

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Nico Williams <[email-masked]>
Date: Fri, 23 Sep 2011 16:43:30 -0500

> which we appear to reaching consensus.

I'd no idea we were reaching consensus.

Nico
--

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 23 Sep 2011 16:30:18 -0700

> I'd no idea we were reaching consensus.

The thing about consensus is that it is subjective, and if dissent is
weak, it is still rough consensus. There weren't too many voices
disagreeing with David B. Now there are two.

So we don't have consensus now. :-)

---

From: <[email-masked]>
Date: Fri, 23 Sep 2011 19:51:27 -0400

> the reason for the lack of UDP transport results in the DNS SRV

If the reason is that UDP can't actually be used, so much the better.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Eisler
> Sent: Friday, September 23, 2011 7:30 PM
> To: Nico Williams
> Cc: [email-masked]