Re: [Gen-art] Gen-ART review of draft-daboo-webdav-sync-07
Russ Housley <housley@vigilsec.com> Fri, 20 January 2012 15:36 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB0621F851C for <gen-art@ietfa.amsl.com>; Fri, 20 Jan 2012 07:36:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.505
X-Spam-Level:
X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC9YAE-CFe6V for <gen-art@ietfa.amsl.com>; Fri, 20 Jan 2012 07:36:37 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 038ED21F8505 for <gen-art@ietf.org>; Fri, 20 Jan 2012 07:36:37 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 51C3BF2401C; Fri, 20 Jan 2012 10:36:46 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id Cs2iaa3ok1kV; Fri, 20 Jan 2012 10:36:15 -0500 (EST)
Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 40F55F240FA; Fri, 20 Jan 2012 10:36:45 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1011@MX14A.corp.emc.com>
Date: Fri, 20 Jan 2012 10:36:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4953A0C3-BB4F-460B-A7AD-34E2840084ED@vigilsec.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94C9@MX14A.corp.emc.com> <250FD273F8360ED86D73260F@cyrus.local> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9F@MX14A.corp.emc.com> <4F184A85.60604@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1011@MX14A.corp.emc.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1084)
Cc: Cyrus Daboo <cyrus@daboo.name>, IETF Gen-ART <gen-art@ietf.org>, arnaud.quillaud@oracle.com
Subject: Re: [Gen-art] Gen-ART review of draft-daboo-webdav-sync-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jan 2012 15:36:38 -0000
I cleared. On Jan 19, 2012, at 5:54 PM, <david.black@emc.com> <david.black@emc.com> wrote: > Hi Peter, > > Yes, the new -07 of this draft is fine, as it resolves issues [1] and [2] as agreed > with the authors, and also resolves issue [3] by changing RFC 5842 from a normative > reference to an informative reference. That change is fine with me, as the references > to RFC 5842 are all for examples that explain some of the synchronization functionality > - it is not necessary to implement any of the requests listed as being specified in > RFC 5842 in order to implement the synchronization functionality. > > Thanks, > --David > >> -----Original Message----- >> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] >> Sent: Thursday, January 19, 2012 11:53 AM >> To: Black, David >> Cc: cyrus@daboo.name; arnaud.quillaud@oracle.com; gen-art@ietf.org; ietf@ietf.org >> Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06 >> >> Hi David, >> >> The text changes that Cyrus proposed have been incorporated into a >> revised I-D: >> >> http://tools.ietf.org/rfcdiff?url2=draft-daboo-webdav-sync-07 >> >> Please let us know if the new version accurately reflects your >> discussion with the authors. >> >> Thanks! >> >> Peter >> >> On 1/2/12 12:55 PM, david.black@emc.com wrote: >>> Hi Cyrus, >>> >>> The proposed changes for the two major issues look good to me: >>> >>> [1] I'm pleased that the concern about adding elements turned out to be a wording issue. >>> >>> [2] Your proposed new text is fine - it provides adequate notice/warning about possible >>> collection inconsistency, so I'm ok with not providing pseudo-code. >>> >>> I'll leave the Downref issue ([3]) for you and Peter to work out with the IESG, and I'm >>> fine with continued use of your name in the examples if that's common practice. >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: Cyrus Daboo [mailto:cyrus@daboo.name] >>>> Sent: Monday, January 02, 2012 2:44 PM >>>> To: Black, David; arnaud.quillaud@oracle.com; gen-art@ietf.org; ietf@ietf.org >>>> Cc: stpeter@stpeter.im >>>> Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06 >>>> >>>> Hi David, >>>> Thank you for your review. Comments inline: >>>> >>>> --On December 27, 2011 11:07:49 PM -0500 david.black@emc.com wrote: >>>> >>>>> [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. >>>> >>>> The first sentence of 3.5.1 is: >>>> >>>> A member URL MUST be reported as changed if it has been mapped as a >>>> member of the target collection since the request sync-token was >>>> generated. >>>> >>>> The term "mapped" implies creation/addition of a new resource in this case. >>>> That may not be obvious to anyone who is not intimately familiar with >>>> WebDAV terminology here, so I propose changing that to: >>>> >>>> A member URL MUST be reported as changed if it has been newly mapped as >>>> a member of the target collection since the request sync-token was >>>> generated (e.g., when a new resource has been created as a child of the >>>> collection). >>>> >>>>> [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. >>>> >>>> Good point. I agree that this deserves some additional text to clarify this >>>> situation. However, I would rather not go into too much detail of how >>>> clients "re-sync" in cases like this as there are a bunch of different ways >>>> that could happen each of which depends on exactly what the client is >>>> trying to do (e.g., in a lot of cases clients will be doing two-way syncs >>>> so will need to reconcile server and local changes within the loop you >>>> propose above - the details of that are not in scope for this >>>> specification). What I propose is the addition of the following paragraph >>>> to the end of Section 3.1: >>>> >>>> Typically, a client will use the synchronization report to retrieve the >>>> list of changes, and will follow that with requests to retrieve the >>>> content of changed resources. It is possible that additional changes to >>>> the collection could occur between the time of the synchronization >>>> report and resource content retrieval, which could result in an >>>> inconsistent view of the collection. When clients use this method of >>>> synchronization, they need to be aware that such additional changes >>>> could occur, and track them through normal means (e.g., differences >>>> between the ETag values returned in the synchronization report and >>>> those returned when actually fetching resource content), conditional >>>> requests as described in Section 5, or repeating the synchronization >>>> process until no changes are returned. >>>> >>>>> [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). >>>> >>>> Working with IESG on this one. >>>> >>>>> Nit: I suggest not using the author's own name (cyrusdaboo) in the >>>>> examples. Someone may copy the code from the resulting RFC. >>>> >>>> This has been common practice in most of the other CalDAV/CardDAV RFCs I >>>> have worked on and has not been the source of any problems, so I would >>>> rather leave this unchanged. If there is an official IETF policy on using >>>> "real names" in examples, then I would be happy to change to follow that, >>>> but I am not aware of anything like that. >>>> >>>>> 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. >>>> >>>> Fixed in my working copy. >>>> >>>> >>>> -- >>>> Cyrus Daboo >>>> >>> >> >
- [Gen-art] Gen-ART review of draft-daboo-webdav-sy… david.black
- Re: [Gen-art] Gen-ART review of draft-daboo-webda… Cyrus Daboo
- Re: [Gen-art] Gen-ART review of draft-daboo-webda… david.black
- Re: [Gen-art] Gen-ART review of draft-daboo-webda… Peter Saint-Andre
- [Gen-art] Gen-ART review of draft-daboo-webdav-sy… david.black
- Re: [Gen-art] Gen-ART review of draft-daboo-webda… Russ Housley