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@xxxxxxx Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf