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-daboo-webdav-sync-06
Reviewer: David L. Black
Review Date: December 27, 2011
IETF LC End Date: December 29, 2011
Summary: This draft is on the right track but has open issues, described in the
review.
This draft specifies new WebDAV functionality that reports on changes to
collections,
enabling a local copy to be kept in sync without retrieving the entire
collection each
time.
I found three open issues, two major, one minor:
[1] -Major- Section 3.5 does not appear to cover the case reporting added
elements on
a subsequent synchronization. The problem may be that the word "changed" as
used in
Section 3.5.1 is assumed to cover adding an element - if so, that's not a good
assumption, and the addition case should be explicitly called out in the title
and
body of Section 3.5.1.
[2] -Major- The operations to retrieve changed members of a collection are not
atomic
wrt the operation that obtains a report on what has changed; collection changes
can occur
between retrieving the report and retrieving the changed elements or while
retrieving the
changed elements. For this reason, simply obtaining a change report and then
retrieving
the elements that have changed according to the report may not result in a
consistent
(e.g., as of a point in time) copy of a collection. I believe that this
absence of
atomicity is a WebDAV "feature", as opposed to a "bug", but I believe that this
behavior
and what to do about it should be discussed in the draft. I suggest the
following,
possibly to the end of section 3.1
i) Add a sentence or two to warn that obtaining a change report and then
retrieving the changed
elements may not result in a consistent local version of the collection if
nothing else is
done because changes may have occurred in the interim.
ii Add a discussion of how to ensure that a local copy of the collection is
consistent.
The basic idea is to re-presented the sync token for that copy to the server
after the
changed elements have been retrieved; the local copy is consistent if the
server reports
that there have been no changes. Some pseudo-code may help, e.g.:
GetSyncCollectionReport(in token, out newtoken, out report);
while (ReportHasChangedItems(report) {
GetChangedItems(report)
token = newtoken;
GetSyncCollectionReport(in token, out newtoken, out report);
}
Actual code should include a counter that counts the number of iterations of
the while
loop and exits with an error if the number of iterations exceeds some limit;
that error
exit implies that the collection is (currently) changing too rapidly to obtain
a consistent
local version.
[3] -Minor- idnits 2.12.12 reports a Downref to RFC 5842. Please consult your
Area
Director (Peter Saint-Andre) to determine what to do about this Downref (it
requires
attention, but may not require changes to the draft).
Nit: I suggest not using the author's own name (cyrusdaboo) in the examples.
Someone
may copy the code from the resulting RFC.
Nit: idnits 2.12.12 reports that draft-ietf-vcarddav-carddav has been published
as RFC 6352;
the RFC Editor will correct this if a new version of the draft is not required
for other
reasons.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf