Subject: RE: heads up - NetApp, NFSv4, and UDP

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 25 Nov 2002 14:37:35 -0800

This seems to be another case in which one section of the spec 
was edited, yet other related sections were left as is, resulting in
contradictions.  There are numerous references to UDP in section
2.2 and also some in section 17.2.  Also ironically, the IETF's
favorite transport, SCTP, that is mentioned in section 3.1 as
one of the approved ones, is not mentioned in those sections
(2.2 and 17.1) so you would have problems in doing an implementation
of NFS over SCTP (couldn't

-----Original Message-----
From: Jim Rees [mailto:[email-masked]]
Sent: Monday, November 25, 2002 5:29 PM
To: [email-masked]
Subject: Re: heads up - NetApp, NFSv4, and UDP 

My copy of the rfc explicitly mentions udp, in section 2.2.  Is my spec out
of date?

My udp rpc follows the recommendations in Van Jacobson, "Congestion
avoidance and Control," Proceedings of SIGCOMM '88, ACM, August 1988.  That
doesn't count?

  It says "the supported transports" (which I read as meaning all of them),
  must be among a set in which UDP is clearly not included.

If this is true, someone needs to fix section 2.2.

---

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Nov 2002 15:22:13 -0800

> of NFS over SCTP (couldn't

I certainly didn't know enough about SCTP to write intelligently about what
the univeral address form for SCTP should be when I drafted the offending
text in 2.2. And having learned more about SCTP since then, it's pretty clear to
me that before one talks about NFSv4 over SCTP one better have a clear idea what
ONC RPC over SCTP means. For example, SCTP apparently has its own record marking.
So should ONC RPC over SCTP use RPC's record marking protocol? If not, that's
a third class of transport semantics that aren't currently covered by the ONC
RPC specifications. Section 17.2 says that an future Information (sic, we'll 
try to fix that typo during the 24 hour pre-publication review period) RFCs
will be required for other transports' RFCs. 

I suppose having a separate RFC for netids would have made things clearer, but
separate RFCs have their own costs and risks.

We'll have to agree to disagree as to whether there's a contradiction or not.
Better yet, review the changes to i-d's during last call.

Another issue for the issues list.

	-mre

---

From: Trond Myklebust <[email-masked]>
Date: 26 Nov 2002 01:36:35 +0100

(Sorry Mike for the duplicates - I meant to CC the list)

>>>>> " " == Mike Eisler <[email-masked]> writes:

     > I certainly didn't know enough about SCTP to write
     > intelligently about what the univeral address form for SCTP
     > should be when I drafted the offending text in 2.2. And having
     > learned more about SCTP since then, it's pretty clear to me
     > that before one talks about NFSv4 over SCTP one better have a
     > clear idea what ONC RPC over SCTP means. For example, SCTP
     > apparently has its own record marking.  So should ONC RPC over
     > SCTP use RPC's record marking protocol?

I'm not sure I understand this. Why would you want to add a record
marking protocol on top of SCTP: doesn't the stream sequence number
suffice to distinguish records?

AFAICS the Linux implementation of SCTP sockets just maps the entire
protocol into the UDP/RAW-style sendmsg()/recvmsg() API.

Cheers,
  Trond