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.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------