Got it: I will add “Since the ChangeSet includes the effective date, the client can apply changes in order.” To the paragraph starting with “Servers supporting this extension…”
Thanks for noticing that Brian > On Jun 23, 2026, at 2:48 PM, Joel Halpern <[email protected]> wrote: > > The third paragraph in the introduction talks about applying the updates in > order. Since the client applies the updates, this led me to expect the > client to be able to infer the order. > Yoyrs, > Joel > Jun 23, 2026 2:42:56 PM Brian Rosen <[email protected]>: > > Joel > > Thank you for your review > > I clearly need to improve the wording. > > The client can’t tell the order of ChangeSets from the IDs. The server can. > Two examples: the Ids are literally incrementing numbers, and alternatively > the IDs are a hash of an incrementing number. The server creates the Ids, so > it knows, in both cases. The client could figure it out in the first case, > but it couldn’t in the second case. > > So, I have to ask, what wording suggested to you that the client can figure > out the order from the IDs? > > To be sure, it really doesn’t matter if the client knows the order: it’s just > dumb - it sends the last ID it got, and asks if there are any newer ones. > The server knows, and returns any IDs that are newer than the ID sent in the > poll. If there weren’t any, the client uses the same ID in the next poll. > If there were, it gets new IDs in response to the poll and uses the last one > it got for the next poll. > > When the client retrieves the ChangeSets from the server, they have the > effective dates in them, so the client knows what order to apply them. > > Brian > > > On Jun 21, 2026, at 8:21 PM, Joel Halpern via Datatracker <[email protected]> > wrote: > > Document: draft-ietf-ecrit-lost-planned-changes > Title: Validation of Locations Around a Planned Change > Reviewer: Joel Halpern > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-ecrit-lost-planned-changes-18 > Reviewer: Joel Halpern > Review Date: 2026-06-21 > IETF LC End Date: 2026-06-30 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is almost ready for publication as a Proposed Standard > > Major issues: > At the veyr least, the description of the relationship between ChangeSetID > and Ordering is confusing. If I have read it right, it is internally > inconsistent. At appears to be the itnent that the client can determine > from two ChangeSetIds which one is older, And a server can determine from > a ChangeSetId what Change Sets are newer than the given one. The latter > can in principle be achieved by the server storing and using timestamps > locally in addition to the ChangeSetIds. It is possible that the > intention > is that clients do not determine ordering from the ChangeSetIds, (The > middle of the third paragraph of the introduction says "IDs are ordered so > that changes can be completed in the correct order.") > > Minor issues: N/A > > Nits/editorial comments: N/A > > > _______________________________________________ > Ecrit mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
