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]
