Brian, please also change "replaces" as I suggested in my email sent on
June 15th, or in some other way.
--Randall
On 23 Jun 2026, at 11:42, Brian Rosen wrote:
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]
