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>
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
Precedence: list

I cleared.


On Jan 19, 2012, at 5:54 PM, <david.black@emc.com> <david.black@emc.com> =
wrote:

> Hi Peter,
>=20
> 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.
>=20
> Thanks,
> --David
>=20
>> -----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
>>=20
>> Hi David,
>>=20
>> The text changes that Cyrus proposed have been incorporated into a
>> revised I-D:
>>=20
>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-daboo-webdav-sync-07
>>=20
>> Please let us know if the new version accurately reflects your
>> discussion with the authors.
>>=20
>> Thanks!
>>=20
>> Peter
>>=20
>> On 1/2/12 12:55 PM, david.black@emc.com wrote:
>>> Hi Cyrus,
>>>=20
>>> The proposed changes for the two major issues look good to me:
>>>=20
>>> [1] I'm pleased that the concern about adding elements turned out to =
be a wording issue.
>>>=20
>>> [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.
>>>=20
>>> 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.
>>>=20
>>> Thanks,
>>> --David
>>>=20
>>>> -----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
>>>>=20
>>>> Hi David,
>>>> Thank you for your review. Comments inline:
>>>>=20
>>>> --On December 27, 2011 11:07:49 PM -0500 david.black@emc.com wrote:
>>>>=20
>>>>> [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.
>>>>=20
>>>> The first sentence of 3.5.1 is:
>>>>=20
>>>>    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.
>>>>=20
>>>> 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:
>>>>=20
>>>>    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).
>>>>=20
>>>>> [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
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.:
>>>>>=20
>>>>> 	GetSyncCollectionReport(in token, out newtoken, out report);
>>>>> 	while (ReportHasChangedItems(report) {
>>>>> 		GetChangedItems(report)
>>>>> 		token =3D newtoken;
>>>>> 		GetSyncCollectionReport(in token, out newtoken, out =
report);
>>>>> 	}
>>>>>=20
>>>>> 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.
>>>>=20
>>>> 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:
>>>>=20
>>>>    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.
>>>>=20
>>>>> [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).
>>>>=20
>>>> Working with IESG on this one.
>>>>=20
>>>>> Nit: I suggest not using the author's own name (cyrusdaboo) in the
>>>>> examples.  Someone may copy the code from the resulting RFC.
>>>>=20
>>>> 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.
>>>>=20
>>>>> 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.
>>>>=20
>>>> Fixed in my working copy.
>>>>=20
>>>>=20
>>>> --
>>>> Cyrus Daboo
>>>>=20
>>>=20
>>=20
>=20