Last Call Review of draft-daboo-webdav-sync-
review-daboo-webdav-sync-genart-lc-black-2011-12-28-00

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