Subject: [nfsv4] Notification delays

From: "david m. richter" <[email-masked]>
Date: Fri, 20 Jan 2006 16:04:21 -0500 (EST)

hello,

	I've a couple small questions about notification delays in section
6.3 in the draft.  First, Saadia's original proposal named them
"child_attr_delay" and "dir_attr_delay"; in the draft they're cryptically
called "supp_child_attr_notice" and "supp_dir_attr_notice".  I propose
"dir_notif_delay" and "dir_entry_notif_delay"  (or "dir_attr_notif_delay",
etc) for clarity.

	Second, I'm curious about the type of those arguments.  Saadia's
original proposal has them as nfstime4, which seems to be realized as
struct timespec.  I wonder what people think of instead using an integer
type in units of seconds.  Is that too coarse, relative to a client's RTT?
Having nanosecond or microsecond precision seems overmuch -- but maybe it
could possibly be important for a client to get notified at 2 or 3 RTTs..?
Would a server want to be able to commit to subsecond delays?  Would that
even help at all with the large-slowly-changing-directories use case?

	thanks,

	d
	.

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

---

From: Mike Eisler <[email-masked]>
Date: Fri, 20 Jan 2006 14:38:14 -0800 (PST)

--- "david m. richter" <[email-masked]> wrote:
ttr4_dir_notify_delay/fattr4_dir_entry_noti
> type in units of seconds.  Is that too coarse, relative to a client's RTT?

I prefer to have a single data type for time representation
in the spec.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 24 Jan 2006 11:41:10 -0600

I have made the name changes: dir_notif_delay and dir_entry_notif_delay
Will be included in next update of the I-D.

Spencer