Re: [Ecrit] WGLC: draft-ietf-ecrit-lost-planned-changes-08

[Roger Marshall <[e-mail]>]

I support draft-ietf-ecrit-lost-planned-changes-08 as part of WGLC.

I have also embedded below, some comments to the draft language - up to and including parts of section 3.


Suggested edits to lost-planned-changes-08

C1. Abstract, (spelling, wording)

From:
   This document defines an extension to the Location to Service
   Translation (LoST) protocol (RFC5222) that allows a LoSR server ti
   notify a client of planned changes to the data.
To:
   This document defines an extension to the Location to Service
   Translation (LoST) protocol (RFC5222) that allows a LoST server to
   notify a client of planned changes to the data it receives.

C2. Abstract, (wording)

From:
This extension is only useful with the validation function of LoST.  It is beneficial for LoST validation clients to be aware of planned changes, as    records that previously were valid may become invalid as of a known future date, and new location may become valid after the date.  This extension adds an element to the <findService> request: a date that allows the LoST client to request that the server perform validation as of the date specified.

To:
This extension is only useful for the validation function of LoST.  It is beneficial for LoST validation clients to be aware of planned changes, as    records that previously were valid may become invalid as of a known future date, and new records may become valid after some future date.  This extension adds an element to the <findService> request: namely, a date that allows the LoST client to request that the server perform validation as of the date specified.

C3.  Introduction, (wording)

From:
Of course, this does not facilitate timely changes, is not coordinated with the actual change event, and also adds significant load to the LoST server as well as the LIS.  Even if re-validation is contemplated, the server has no mechanism to control or even suggest the time period for revalidation.

To:
Of course, this does not facilitate timely changes, is not coordinated with the actual change event, and adds significant load to the LoST server as well as the LIS.  Even if re-validation is contemplated, the server has no mechanism to control or suggest the time period for revalidation.

C4. Introduction, (delete sentence or make it clearer as to how IDs are ordered)

From:
A set of such partial locations is termed a "ChangeSet". ChangeSets have an ID, and a date when the change is effective. IDs are ordered.

To:
A set of such partial locations is termed a "ChangeSet". ChangeSets have an ID, and a date when the change is effective.

C5. Section 3., Planned Change Poll Interface, (reword)

From:
Entry point two, PlannedChangePoll,is a poll.  The poll returns a list of changeSetIds which identify ChangeSet objects.

To:
Entry point two, PlannedChangePoll,supports a polling mechanism.  The poll returns a list of changeSetIds which identify ChangeSet objects.

C6. Section 3., (grammar, 2 places)

From:
clients records [and] client's records

To:
client records [and] client records

C7. Section 3., (reword)

From:
a partial location with Country, A1, A2, A3, A4, RD and POD but not HN means any address number on the specified street.

To:
a partial location with Country, A1, A2, A3, A4, RD and POD but not HN applies to any address number on the specified street.

C8. Section 3., (clarify "id" types, and change wording)

From:
The changeSetId is string, which the server maintains as an ordered list of changeSetIds.  The id itself may not show the ordering.  For example, it could be a hashed timestamp, or a hashed sequence number. Given a changeSetId returned by it in a prior poll, the server can identify which ChangeSets it has that come after, in order, after the one with the proffered changeSetId.  A new client does not know any ids, or a client may lose the id that it had. The client would poll omitting the changeSetId in the poll query, and in response, the server returns all the ChangeSets it knows about.

To:
The changeSetId is a string, which the server maintains as an ordered list of changeSetIds.  The id itself may not show the ordering.  For example, the id could be a hashed timestamp, or a hashed sequence number, among other things. Given a changeSetId returned in a prior poll, the server can identify which ChangeSets it has that come next, in order, after the one with the proffered changeSetId.  To support a new client that does not know any ids, or a client that may have lost the id that it had, the client would poll, omitting the changeSetId in the poll query. In response, the server returns all the ChangeSets it knows about.

-roger marshall.