Subject: RE: Why does CB_* require a return path?

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 30 May 2002 12:56:06 -0700

Because I wasn't foresighted enough?

Anyway it would be nice to fix this now (if only to save me from more
embarassment as people keep asking about it).  This isn't a case of
"now or never" but since nobody has even proposed a start date for
work on an NFS-v4.1, it is a case of "now or some time after 2005",
which isn't very attractive either.

My big concern with adding anything at this point is the workload
for our editor, and the possiblity of delaying even further the new
hopefully final Proposed Standard.  This isn't a big thing but given
where we are now, every little bit hurts.

As a way of ameliorating this concern, could we have a volunteer (like
Jim perhaps) who would come up with a set of precise spec updates (at
essentially the level of diffs) ready to go in if there is consensus
on this issue.

-----Original Message-----
From: Jim Rees [mailto:[email-masked]]
Sent: Thursday, May 30, 2002 3:09 PM
To: [email-masked]
Subject: Re: Why does CB_* require a return path? 

And it would be so easy to fix, for example by specifying that the reserved
r_addr "--SOURCE--" means that callbacks should go back to the source.  It's
one thing to say that callbacks aren't required for proper operation, but to
prohibit their use from behind a nat is a shame.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 30 May 2002 15:44:27 -0500

My response of "not now" was driven by the fact that no one had
provided specific suggestions or interest in the issue when Brent
originally raised it.  At this point, if an issue is raised and does
not have a specific modification included, I don't consider it close
to consensus.

I agree that bidirectional RPCs would be useful in this context but
currently don't have the bandwidth or interest to resolve the issues
that I pointed out and any others that pop up once those are accounted
for...

As Dave suggests, if someone were to provide a specific set of
modifications to specification that addressed the issues raised --
Great.

-- 
Spencer