Subject: Re: [nfsv4] [3530bis] Driving another nail into the UDP coffin

From: RJ Atkinson <[email-masked]>
Date: Fri, 7 Oct 2011 15:01:06 -0400

Hi,

* NORM, despite the "reliable multicast" part of its name, is often
  used for unicast sessions.  The NORM specification notes that it
  complies with IETF congestion avoidance/control guidelines.
  My recollection, possibly wrong, is that NORM is always layered 
  on top of UDP.  [RFC-5740]  I further understand that NORM is readily 
  available, including at least one open-source implementation by NRL.

* Datagram Congestion Control Protocol (DCCP) is an IETF blessed
  approach to laying congestion avoidance/control on top of UDP.
  [RFC-4340, RFC-4341, RFC-4342, along with several "profile" RFCs]
  I understand that this also is readily available.

So it seems to me that it is possible to use UDP in a way
that provides reliable delivery and also complies with IETF
congestion avoidance/control guidelines.

Personally, I'm a big fan of running NFS/TCP -- on the practical
grounds that it consistently works better operationally in 
my environments.  So please don't mistake this note as some 
sort of "UDP advocacy".

However, it seems preferable that if the NFS WG decides to more
clearly deprecate NFS/UDP, that decision ought to be based 
on technical claims/concerns/issues OTHER THAN these,

  (1) UDP cannot provide congestion avoidance/control
  (2) UDP cannot provide reliable delivery.

for the practical reason that NORM & DCCP are existence
proofs that UDP can provide both of those properties.

Cheers,

Ran

---

From: <[email-masked]>
Date: Mon, 10 Oct 2011 11:56:07 -0400

> proofs that UDP can provide both of those properties. 

But your examples show no such thing.

DCCP is providing (1), while NORM provides (2).  UDP is 
providing neither.  As a contrast, TCP does provide both of these.
And that is why the spec has a thumbs-up for TCP and a thumbs-down 
for UDP.

We don't want to go back to the confusion of "by itself" but if
it needs to be clearer, we have to stress that we are simply saying
that your can't use UDP as the transport protocol and not that you
can't use UDP within the transport protocol.  UDP may be bad as an
NFSv4 transport protocol but it is not some horrible virus that somehow 
manages to corrupt all protocols that it operates with.  Is there anything 
in the spec that might somehow lead people to think that we are crazy 
enough to think that it is?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: Friday, October 07, 2011 3:01 PM
To: [email-masked]
Subject: Re: [nfsv4] [3530bis] Driving another nail into the UDP coffin

Hi,

Cheers,

Ran

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

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 18 Oct 2011 08:38:42 -0400

On 10  Oct 2011, at 11:56 , <[email-masked]> <[email-masked]> wrote:
> DCCP is providing (1), while NORM provides (2).  

My understanding, both from reading the RFCs and from discussions
with NORM experts, is that NORM provides both (1) and (2).  

Also, as noted before, NORM is not limited to multicast-only 
(despite the M word in the name) and is often used for unicast traffic.

At least one possible plain-language reading of the DCCP specification 
set indicates that DCCP also can provide both (1) and (2).

Both of these normally use UDP as part of the transport-layer 
implementation.  

(NOTE:  I'd rather side-step the philosophical question of whether 
NORM or DCCP are part of the transport-layer or are instead part of 
some hypothetical session-layer, since that seems like a rat hole to me.)

> UDP is providing neither.  As a contrast, TCP does provide both of these.

I was suggesting that the NFS mailing list discussion seemed either
confused or incomplete, as UDP+DCCP or UDP+NORM appear to provide 
the properties of reliability and IETF-approved congestion-avoidance.

I don't think there is any disagreement that it would be unwise 
to deploy NFS/UDP *without* also using NORM or DCCP to remedy the
limitations of using UDP alone.

> can't use UDP within the transport protocol.  

I very much would welcome either editing to make that point more clear,
or some other language (example next paragraph) that would avoid begging 
the question about UDP+NORM or UDP+DCCP.

From my own operational perspective, I'd be equally happy with removing 
the (at present) confusing discussion of transport protocol properties
and making the much simpler statement (edit to taste) that:

	"To maximise interoperability, NFSv4 always runs over TCP."

For me interoperability is the biggest issue.  Having more than one
way of carrying NFS information at the transport-layer impedes,
rather than helps, NFS interoperability in the deployed world.

Yours,

Ran Atkinson

DISCLAIMER:
I'm speaking for myself only, as an NFS operations person;
I'm not an NFS coder, but one hopes that NFS operations
folks views will also be taken seriously (and in the friendly
way they are intended).

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 11:50:27 -0400

> some hypothetical session-layer, since that seems like a rat hole to me.) 

I agree it is a rat hole.  I'd prefer to take a long running start and jump
over it.  If you just try to sidestep it, you may somehow get caught, twist
your ankle etc.

I think we don't need to refer to "the transport" but merely whatever NFS runs
over, regardless of your lamination philosophy.

> rather than helps, NFS interoperability in the deployed world.

I'd be fine with it, but the IESG wouldn't be.

Disallowing SCTP, would be a non-starter there, and your operational
perspective would lose out.

TCP + SCTP only won't work since the interoperability argument is no longer 
valid then. 

So it look like we are backed into the transport characteristics corner, unpleasant
as it is.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: Tuesday, October 18, 2011 8:39 AM
To: [email-masked]
Subject: Re: [nfsv4] [3530bis] Driving another nail into the UDP coffin

Yours,

Ran Atkinson

DISCLAIMER:

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 18 Oct 2011 12:30:11 -0400

> I'd be fine with it, but the IESG wouldn't be.

Please do tell.

Has the IESG been officially asked ?  

Has there been official communication from the IESG about that ?
If yes, a URL to a public IESG note would be very welcome.

Are there any actual implementations of NFS/SCTP ?
-- If not yet, is there reason to believe that NFS/SCTP
   will be implemented anytime soon ?
-- If yes, are there any known deployments of NFS/SCTP ?

> Disallowing SCTP, would be a non-starter there,

[ASIDE:  I like SCTP myself, for various reasons, and can
imagine using it for various purposes (e.g. selected kinds
of server multi-homing within a single administrative domain),
but I like interoperability even more.]

Unfortunately, SCTP is itself largely a non-starter for NFS, 
except MAYBE inside private network deployments, since SCTP 
[isn't supported | doesn't work] through any NAT or any firewall 
that I can identify.  Most IPv6 deployments still involve
at least firewalling, so IPv6 is not an obvious "fix"
for this issue.

By contrast, wide-Area deployments of NFS/TCP are reasonably
common and do work through virtually any NAT/NAPT device
and also through virtually any firewall device.

[Off-list pointers to specific commercial firewall/NAT 
devices that DO support SCTP would be welcome, but would not
change the reality that SCTP is not today readily deployable 
through existing deployed firewall/NAT infrastructures.]

> and your operational perspective would lose out.

Hmm.  I'm not sure what you mean by that.

The operational perspective is valid regardless of IETF decisions.  
Of course, other perspectives also exist and also need to be 
considered by the WG and by the IESG.  The whole point of the 
(oft cumbersome) IETF processes is to consider all perspectives 
and try to balance among different perspectives.

Pending answers to my questions up top (perhaps I just lost
the plot at some point and simply need some education), 
it is not obvious that such consideration has occurred 
on this narrow topic.

> TCP + SCTP only won't work since the interoperability argument
> is no longer valid then. 

That claim isn't obvious to me, at least.

Why not ?

Fewer deployment options still increases the probability of
interoperability over more deployment options -- this is 
neither news nor disputable in the scientific world.

> So it look like we are backed into the transport
> characteristics corner, unpleasant as it is.

At the moment, that conclusion is not obvious to me.

If that conclusion stands, then editing is still needed,
to avoid "begging the question" about whether it is valid
to run NFS over UDP+NORM and/or UDP+DCCP.

Yours,

Ran

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 14:42:12 -0400

To clarify, my belief is what it is and I am not sure
about it.  If you want someone to deal with the IESG on
this issue, I would suspect Spencer or Beepy would have more luck
than me.  Sorry guys. 

I have no reason to believe NFS/SCTP will be implemented in my 
lifetime.  But I don't think that is all that relevant to the 
issue.   Are we saying that we should prohibit it, so that 
we will be sure that nobody will?  If so, why? 

> Hmm.  I'm not sure what you mean by that.

I mean your valid perspective implying that we should simply say 
"the TCP way or the highway" will not be assented to by all those
That need to assent to it for us to publish on that basis. 

> The operational perspective is valid regardless of IETF decisions.  

I agree, but that doesn't mean such a perspective can be embraced
by IETF documents.

> and try to balance among different perspectives.

That may be the intention, but there is bound to be a difference
among:
    - trying to balance
    - balancing
    - balancing resulting in an appropriate result

> it is not obvious that such consideration has occurred 

Some perspectives have been balanced but you or I may not agree with
the result, and even if we do, requiring obviousness is a little too
demanding.

Perhaps I'm unduly skeptical about the process but after seeing what happened 
with I18n in RFC3530, I want to be clear that good intentions do not ensure 
an appropriate result. 

> That claim isn't obvious to me, at least.

Again with obviousness standard.  It's just too vague.

You know the story ...

    A mathematician is teaching a class doing a proof.

    "now it is obvious that for each a, and b, there always exists a c
     such that ..."

    "wait a minute.  Is that obvious?"

    Leaves the room.  Comes back in twenty minutes.

    "Yes, it is obvious".  :-)

> neither news nor disputable in the scientific world.

Sure but it isn't clear why two are chosen (and why those two),
while for one the situation is clear.  You have the probability of
interoperability increasing very slowly as the number of transports 
Allowed goes down, and then going suddenly up to 100% as the number 
goes down to one (and back down to 0% as the number goes to zero :-)

> At the moment, that conclusion is not obvious to me.

If you think it is wrong, tell me why?

> to run NFS over UDP+NORM and/or UDP+DCCP.

Agree but I prefer editing to dealing with IESG about SCTP.
YMMV.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: Tuesday, October 18, 2011 12:30 PM
To: [email-masked]
Subject: Re: [nfsv4] [3530bis] Driving another nail into the UDP coffin

Please do tell.

Why not ?

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 18 Oct 2011 17:45:02 -0400

On 18  Oct 2011, at 14:42 , <[email-masked]> wrote:
> about it.  

I guess that begs a different question:

	Is anyone sure about that NFS/SCTP is important to anyone ?

> we will be sure that nobody will?  If so, why? 

For other applications, it is very very common for the IETF
to specify a single transport-layer approach -- meaning precisely
TCP xor UDP.  There are LOTS of precedents for that.  

A few obvious examples include (SMTP, telnet, SSH) all of which
always run over TCP -- not UDP, not UDP+NORM, not UDP+DCCP,
and not SCTP.

I do not understand why some here believe that this WG
can not make a similar decision.  There are ample 
precedents within the IETF to pick a single transport protocol
and for TCP to be the one chosen transport protocol.

> That need to assent to it for us to publish on that basis. 

Can we at least CHECK whether the WG would agree that going
forward NFS/TCP (or some minimal set) is acceptable,
rather than work on the basis of an uncertain belief ?  

> I agree, but that doesn't mean such a perspective can be embraced

The operational perspective often is embraced by many other IETF documents.

> with I18n in RFC3530, I want to be clear that good intentions do not ensure 

I won't claim that IETF outcomes are always perfect; 
we all know that the outcomes vary based on a wide range of variables.

> while for one the situation is clear.  

Well, a good start is that if no one is going to implement NFS/foo,
then we ought not create a needless confusion about whether
NFS/foo is something that the IETF specifications embrace/allow.

> If you think it is wrong, tell me why?

No one can point to any public IESG position saying that NFS
needs to forego interoperability and must support multiple
transport protocols.  Such a position would be contradictory
given past precedents in IESG decisions about other application
protocols.

So, far as I can tell, that is simply a false assumption.

I've asked for a pointer to a public statement supporting your
belief (about which you acknowledge uncertainty), but I haven't
seen one from anyone yet. 

If the WG Chairs know of specific IESG concerns in this area,
it surely would help to make that information public on this
WG's mailing list.  

If no one can produce a specific statement, that supports
my belief that the assumption below is not correct.

UNVERIFIED ASSUMPTION:
	"NFS needs to be specified in a way that allows any
	reliable transport-layer protocol to be used for NFS"

> Agree but I prefer editing to dealing with IESG about SCTP.

I'd really prefer to have a good specification that provides
excellent interoperability.  I have no reason at this point
to believe that the IESG care about NFS/SCTP.

(If an AD can clarify this, that would surely help. :-)

Yours,

Ran

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 18 Oct 2011 22:32:50 +0000

> Sent: Tuesday, October 18, 2011 2:45 PM
> To: [email-masked]
> > To clarify, my belief is what it is and I am not sure about it.
> 
> For other applications, it is very very common for the IETF to specify a
> single transport-layer approach -- meaning precisely TCP xor UDP.  There
> are LOTS of precedents for that.
> 
> A few obvious examples include (SMTP, telnet, SSH) all of which always run
> over TCP -- not UDP, not UDP+NORM, not UDP+DCCP, and not SCTP.
> 
> I do not understand why some here believe that this WG can not make a
> similar decision.  There are ample precedents within the IETF to pick a
> single transport protocol and for TCP to be the one chosen transport
> protocol.
> 
> > I mean your valid perspective implying that we should simply say "the
> > TCP way or the highway" will not be assented to by all those That need
> > to assent to it for us to publish on that basis.
> 
> Can we at least CHECK whether the WG would agree that going forward
> NFS/TCP (or some minimal set) is acceptable, rather than work on the basis
> of an uncertain belief ?
> 
> > I agree, but that doesn't mean such a perspective can be embraced by
> > IETF documents.
> 
> > Perhaps I'm unduly skeptical about the process but after seeing what
> > happened with I18n in RFC3530, I want to be clear that good intentions
> > do not ensure an appropriate result.
> 
> I won't claim that IETF outcomes are always perfect; we all know that the
> outcomes vary based on a wide range of variables.
> 
> >>> TCP + SCTP only won't work since the interoperability argument is no
> >>> longer valid then.
> >> interoperability over more deployment options -- this is neither news
> >> nor disputable in the scientific world.
> >
> > Sure but it isn't clear why two are chosen (and why those two), while
> > for one the situation is clear.
> 
> Well, a good start is that if no one is going to implement NFS/foo, then
> we ought not create a needless confusion about whether NFS/foo is
> something that the IETF specifications embrace/allow.
> 
> >>> So it look like we are backed into the transport characteristics
> >>> corner, unpleasant as it is.
> >
> No one can point to any public IESG position saying that NFS needs to
> forego interoperability and must support multiple transport protocols.
> Such a position would be contradictory given past precedents in IESG
> decisions about other application protocols.
> 
> 
> I've asked for a pointer to a public statement supporting your belief
> (about which you acknowledge uncertainty), but I haven't seen one from
> anyone yet.
> 
> If the WG Chairs know of specific IESG concerns in this area, it surely
> would help to make that information public on this WG's mailing list.
> 
> If no one can produce a specific statement, that supports my belief that
> the assumption below is not correct.
> 
> UNVERIFIED ASSUMPTION:
> >> If that conclusion stands, then editing is still needed, to avoid
> >> "begging the question" about whether it is valid to run NFS over
> >> UDP+NORM and/or UDP+DCCP.
> >
> I'd really prefer to have a good specification that provides excellent
> interoperability.  I have no reason at this point to believe that the IESG
> care about NFS/SCTP.

NFSv4 has had the position of inclusiveness for transports.  The one direction
we have from the IESG is the need for congestion control for transports that
under the guise of the IETF.  NFS/RDMA does exist and allows for the use of
NFS directly over Infiniband and of course, that is not an IETF defined transport
and thus outside of the need to define/use a congestion control mechanism.

Ran, your suggestion that the NFSv4 RFCs make a specific statement about
the use of TCP to the exclusion of other transports has just not been
thought of in the working group.  We don't have an IESG directive saying
we have to keep the door open for other transports; the working group
has had this mindset mainly because it seemed like a good idea not to
exclude the use of other transports.

Now that the suggestion has been made, are there other opinions for or against
such a "TCP only" statement for NFSv4?

I am not sure the working group cares much about NFS/SCTP.  SCTP has 
certainly existed for long enough for us to notice.  We did have a
definition of sorts of RPC over SCTP but even that change went larger
unnoticed and forgotten until a recent discussion.

Spencer

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 18 Oct 2011 19:40:49 -0400

On 18  Oct 2011, at 18:39 , Nico Williams wrote:
> IMO: exclude UDP explicitly,

Request for clarification:
	(UDP + NORM) ??
	(UDP + DCCP) ??

> and say that SCTP will be defined if and when it becomes
> desirable and because it solves problems that might be
> too hard to solve with TCP otherwise.

The SCTP text above seems generally reasonable to me,
although I'd suggest:
	s/might be/are/

In short, define NFS/SCTP only if technical issues force
NFS in that direction.

Yours,

Ran

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 18:55:22 -0500

> Request for clarification:

UDP without DCCP.  Dunno what NORM is.

But really, why bother with UDP in any shape?  Sure, this would be a
statement of current WG mood^H^H^H^Hconsensus.  I think it's more than
fair to say that no one here wants to bother with UDP, no matter what
toppings one might add to it.

> The SCTP text above seems generally reasonable to me,

:)

> In short, define NFS/SCTP only if technical issues force

Yes.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 17:39:32 -0500

IMO: exclude UDP explicitly, and say that SCTP will be defined if and
when it becomes desirable and because it solves problems that might be
too hard to solve with TCP otherwise.

Nico
--

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 18 Oct 2011 19:43:57 -0400

On 18  Oct 2011, at 18:32 , Spencer Shepler wrote:
> NFSv4 has had the position of inclusiveness for transports.  

My understanding, possibly confused, is that this is largely historical,
dating back to the days of NetDisk (pre-NFS) when TCP was not widely
understood to work well for distributed file system purposes.

> The one direction we have from the IESG is the need for
> congestion control for transports that under the guise of the IETF.  

Thank you very much for the clarification.

> NFS/RDMA does exist and allows for the use of NFS directly over
> Infiniband and of course, that is not an IETF defined transport

Agreed.

> We don't have an IESG directive saying we have to keep the door open
> for other transports; the working group has had this mindset mainly
> because it seemed like a good idea not to exclude the use of other transports.

Thank you very much for the clarification.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 19 Oct 2011 07:51:56 -0400

> toppings one might add to it.

OK.  Then how about language like this (edit to taste):

	"UDP is not used as an NFSv4 transport; neither 
	 UDP alone nor UDP in combination with some other 
	 mechanism (e.g. DCCP, NORM) are used for NFSv4."

Cheers,

Ran

---

From: Daniel Ellard <[email-masked]>
Date: Wed, 19 Oct 2011 09:25:45 -0400

>         mechanism (e.g. DCCP, NORM) are used for NFSv4."

I think it would be more effective to focus what characteristics of
the transport are required, rather than specific examples, although
examples are fine for clarifications.

For example: "The requirements are <as stated>.  Examples of protocols
that satisfy these requirements are TCP, SCTP, and RDMA[1].  UDP is an
example of a protocol that does not."

I might even go further: "Implementations SHOULD support TCP, and MAY
support additional protocols."

I wouldn't mention NORM or DCCP anywhere; they're red herrings.  I
don't know much about DCCP, but from reading the intro to the RFC, I
don't see why anyone would find this a compelling transport for NFS.
I do know a bit about NORM, and although NORM is well-suited for its
intended purpose, the idea of running NFS over a multicast protocol
seems deeply silly.

[1] Assuming this is true of RDMA.

-Dan

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 14:18:06 -0400

> examples are fine for clarifications. 

One might think so, but in fact, we have not had much luck following this
rational sort of approach.

There's been no argument about using UDP per se, but the precise requirements
that "justify" this exclusion and quasi-metaphysical layering issues keep 
taking up time.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Ellard
Sent: Wednesday, October 19, 2011 9:26 AM
To: [email-masked]
Subject: Re: [nfsv4] [3530bis] Driving another nail into the UDP coffin

-Dan

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 14:38:04 -0400

The classic mantra is that IETF is about "rough consensus and running code" - this
discussion of transport protocol requirements is in the "rough consensus" category,
so perhaps something in the "running code" category would be helpful ;-).

Ran actually mentioned this in his message that started this whole thread:

>	"To maximize interoperability, NFSv4 always runs over TCP."

While I suspect that WG "rough consensus" won't permit removal of the transport
protocol requirements discussion, a sentence or two to point out "It uses TCP,
stupid!" :-) along the lines that Ran suggested would be another strong nail
for the UDP coffin ;-).

FWIW, I make this suggestion as a member of the OPS Area Directorate, if that helps.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, October 19, 2011 2:18 PM
> To: [email-masked]; [email-masked]

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 19 Oct 2011 19:24:01 +0000

At this point, running code wins the day.  NFSv4 has been in existence
for long enough to allow advocates of other transport usage to make
their case.  TCP is it for IETF transports and NFS/RDMA allows for
the other interesting path.

If an additional transport becomes interesting in the future, a separate
standards track I-D can be developed to explain its use for NFSv4
and we can build consensus around that.

Now it seems we are down to what words to use in the 3530bis document
and any errata we might file against 5661.

Spencer

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, October 19, 2011 11:38 AM
> To: [email-masked]; [email-masked]
> The classic mantra is that IETF is about "rough consensus and running
> code" - this discussion of transport protocol requirements is in the
> "rough consensus" category, so perhaps something in the "running code"
> category would be helpful ;-).
> 
> > From my own operational perspective, I'd be equally happy with
> > removing the (at present) confusing discussion of transport protocol
> > properties and making the much simpler statement (edit to taste) that:
> >
> While I suspect that WG "rough consensus" won't permit removal of the
> transport protocol requirements discussion, a sentence or two to point out
> "It uses TCP, stupid!" :-) along the lines that Ran suggested would be
> another strong nail for the UDP coffin ;-).
> 
> > One might think so, but in fact, we have not had much luck following
> > this rational sort of approach.
> >
> > There's been no argument about using UDP per se, but the precise
> > requirements that "justify" this exclusion and quasi-metaphysical
> > layering issues keep taking up time.
> >
> > >> But really, why bother with UDP in any shape?  Sure, this would be
> > >> a statement of current WG mood^H^H^H^Hconsensus.  I think it's more
> > >> than fair to say that no one here wants to bother with UDP, no
> > >> matter what toppings one might add to it.
> > >

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 16:01:38 -0400

> and we can build consensus around that. 

I think this is the right approach.  It addresses interoperability
concerns without presuming to judge future needs.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 3:24 PM
To: Black, David; Noveck, David; [email-masked]; RJ Atkinson
Subject: RE: [nfsv4] [3530bis] Driving another nail into the UDP coffin

Spencer

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 27 Oct 2011 15:40:43 +0000

Time for some consensus. Here is what I am proposing as the change in
3530bis:

    <t>
      To date, all NFSv4 implementations are TCP based, i.e., there are
      none for SCTP nor UDP. UDP by itself is not sufficient as a
      transport for NFSv4, neither is UDP in combination with some other
      mechanism (e.g., DCCP <xref target="RFC4340" />, NORM <xref
target="RFC3940" />).
    </t>

All other references to UDP have been removed from the document.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Oct 2011 04:47:45 -0400

> All other references to UDP have been removed from the document.

No objection.

I would prefer to add a sentence (edit to taste) that would
note the interoperability advantages of having a single transport
for NFSv4.  As this is purely a statement of reality, one would
hope this suggestion would not be controversial.

Candidate sentence to add (edit to taste):

	"Interoperability of NFSv4 implementations is maximised 
	 by having a single defined transport protocol (i.e. TCP) 
	 for use with NFSv4."

Yours,

Ran Atkinson