Re: [Ecrit] Comments on draft-ietf-ecrit-lost-planned-changes-09

[Brian Rosen <[e-mail]>]

Yeah, not doing well on making progress.  No excuses.  Traveling this week and next but will try to make progress anyway.  I did have a private conversation with Dan Banks that gave me most of what I needed to actually make the changes he suggested.

Brian


> On Nov 7, 2023, at 6:52 AM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> When could we expect a revision addressing this feedback?
> 
> -MSK
> 
> On Sun, Sep 10, 2023 at 2:54 AM Randall Gellens <[e-mail] <mailto:[e-mail]>> wrote:
>> I have the following list of suggested changes (both editorial and substantive) to draft-ietf-ecrit-lost-planned-changes-09:
>> 
>> (1)
>> ABSTRACT
>> 
>> OLD:
>> notify a client of planned changes to the data it receives
>> 
>> NEW:
>> notify a client of planned changes to location data
>> 
>> ("it" is ambiguous, and "receives" is also unclear since it's referencing future events).
>> 
>> (2)
>> ABSTRACT
>> 
>> OLD:
>> useful for the validation function
>> 
>> NEW:
>> useful with the validation function
>> 
>> (the extension is used with a function)
>> 
>> (3)
>> ABSTRACT
>> 
>> OLD:
>> 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.
>> 
>> NEW:
>> since at a known future date, previously valid records may become
>> invalid, and new records may become valid.
>> 
>> (4)
>> ABSTRACT
>> 
>> OLD:
>> 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.
>> 
>> NEW:
>> This extension adds an element to the <findService> request that
>> allows a LoST client to request validation as of a specified date.
>> 
>> (5)
>> 
>> Introduction
>> OLD:
>> the LIS operator
>> 
>> NEW:
>> a LIS operator
>> 
>> (6)
>> 
>> Introduction
>> OLD:
>> the server has no
>> 
>> NEW:
>> a server has no
>> 
>> (7)
>> 
>> Introduction
>> OLD:
>> to obtain from the LoST server
>> 
>> NEW:
>> to obtain from a LoST server
>> 
>> (8)
>> 
>> Introduction
>> OLD:
>> in the order they were made
>> 
>> NEW:
>> in the correct order
>> 
>> (9)
>> 
>> Introduction
>> OLD:
>> allows the client to poll the server
>> 
>> NEW:
>> allows a client to poll a server
>> 
>> (10)
>> 
>> Introduction
>> OLD:
>> response to the poll
>> 
>> NEW:
>> response to a poll
>> 
>> (11)
>> 
>> Introduction
>> OLD:
>> will be used by the client
>> 
>> NEW:
>> is used by the client
>> 
>> (12)
>> 
>> Introduction
>> OLD:
>> change, the LIS may use
>> 
>> change, a LIS may use
>> 
>> (13)
>> 
>> Introduction
>> OLD:
>> In its response, the LoST server
>> 
>> NEW:
>> In its response, a LoST server
>> 
>> (14)
>> 
>> Introduction
>> OLD:
>> include a new "expires"
>> 
>> NEW:
>> include the new "expires"
>> 
>> (15)
>> 
>> Introduction
>> OLD:
>> rather than blindly revalidating every address on a schedule chosen by the client.
>> 
>> NEW:
>> to avoid clients blindly revalidating every address on an arbitrary schedule.
>> 
>> (16)
>> 
>> Introduction
>> Question: Is the "expires" element restricted to responses to an "asOf" request? If so, this should be stated. If not, then I suggest:
>> 
>> (15a) Separate the paragraph at the period in "of the effective date. In its"
>> 
>> (15b) Change:
>> 
>> OLD:
>> In its response, the LoST server may include a new "expires" element that expressly states when the location should be re-validated, rather than blindly revalidating every address on a schedule chosen by the client.
>> 
>> NEW (also new paragraph):
>> In a <findServiceResponse>, a LoST server may include the new
>> "expires" element to expressly state when the location should be
>> re-validated>. This avoids clients blindly revalidating every address
>> on an arbitrary schedule.
>> 
>> (16)
>> 
>> Introduction
>> OLD:
>> allows the LIS
>> 
>> NEW:
>> allows a LIS
>> 
>> (17)
>> 
>> Introduction
>> OLD:
>> the data in the LIS
>> 
>> NEW:
>> the data in a LIS
>> 
>> (18)
>> 
>> Introduction
>> OLD:
>> However, the LoST server
>> 
>> NEW:
>> However, LoST servers
>> 
>> (19)
>> 
>> Introduction
>> OLD:
>> adds a "expires"
>> 
>> NEW:
>> adds an "expires"
>> 
>> (20)
>> 
>> Introduction
>> OLD:
>> the server to the LIS of when validation
>> 
>> NEW:
>> the a server to a client as to when revalidation
>> 
>> (21)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> a new interface to the
>> 
>> NEW:
>> a new interface to a
>> 
>> (22)
>> 3. Planned Change Poll Interface
>> 
>> Consider making the interfaces/entry points a numbered or bulleted list.
>> 
>> (23)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> returns the ChangeSet object which contains the identifier
>> 
>> NEW:
>> returns a ChangeSet object, which contains an identifier
>> 
>> (24)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> The client compares
>> 
>> NEW:
>> A LoST client (such as a LIS) compares
>> 
>> (25)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> may have a Country
>> 
>> NEW:
>> may have Country
>> 
>> (26)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> change regardless
>> 
>> NEW:
>> change, regardless
>> 
>> (27)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> The changeSetId is string, which the server maintains as an ordered list of changeSetIds
>> 
>> NEW:
>> Servers maintain an ordered set of changeSetId values. Each changeSetId is a string.
>> 
>> (28)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> after the one with the proffered changeSetId
>> 
>> NEW:
>> after the specified changeSetId
>> 
>> (29)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> lost the id
>> 
>> NEW:
>> lost the last changeSetId
>> 
>> (30)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> would poll, omitting the changeSetId in the poll query.
>> 
>> NEW:
>> performs a poll without a changeSetId.
>> 
>> (31)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> ChangeSet returned by the server
>> 
>> NEW:
>> ChangeSet returned by a server
>> 
>> (32)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> keep change sets
>> 
>> NEW:
>> keep ChangeSets
>> 
>> (32)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> A 12
>> 
>> NEW:
>> A twelve
>> 
>> (33)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> where a 3
>> 
>> NEW:
>> while a three
>> 
>> (34)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> fast changing service area where many changes occur regularly.
>> 
>> NEW: EITHER:
>> service area where many changes occur regularly.
>> 
>> OR:
>> fast-changing service area.
>> 
>> (35)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> client in a fast changing
>> 
>> NEW:
>> client in a fast-changing
>> 
>> (37)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> poll is no
>> 
>> NEW:
>> poll contains no
>> 
>> (38)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> knows about, and that same
>> 
>> NEW:
>> knows about; the client uses that same
>> 
>> (39)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> service it supports
>> 
>> NEW:
>> service the server supports
>> 
>> (40)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> document describes version
>> 
>> NEW:
>> document specifies version
>> 
>> (41)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> are integers
>> 
>> NEW:
>> are integers, and a version description is a string consisting of the major version, a dot, and the minor version.
>> 
>> (42)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> they do not implement
>> 
>> NEW:
>> they do not recognize
>> 
>> (42)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> Minor version definitions SHALL
>> 
>> NEW:
>> Minor version specifications SHALL
>> 
>> (43)
>> 3. Planned Change Poll Interface
>> 
>> OLD:
>> would be written as
>> 
>> NEW:
>> is written as
>> 
>> (44)
>> 4. <plannedChange> element
>> 
>> OLD:
>> called "zHxogxRv8SoYre6p1feA7odJF7a0SlwKhPwv". This element contains an attribute: 'asOf'
>> 
>> NEW:
>> called "asOf"
>> 
>> (45)
>> 4. <plannedChange> element
>> 
>> Question: Are there any restrictions on <asOf>? Can it be any date in the past or future? Is there a defined response if the server does not have data for the requested date (e.g., noDataForDate)?
>> 
>> (46)
>> 4. <plannedChange> element
>> 
>> OLD:
>> changes in the LIS commensurate
>> 
>> NEW:
>> changes in its data in accordance
>> 
>> (47)
>> 5. "expires" in Response
>> 
>> OLD:
>> the 'expires'; attribute
>> 
>> NEW:
>> the 'expires' attribute defined here,
>> 
>> (48)
>> 5. "expires" in Response
>> 
>> OLD:
>> persist in the client
>> 
>> NEW:
>> persist in clients
>> 
>> (49)
>> 5. "expires" in Response
>> 
>> OLD:
>> the URI mechanism is widely deployed at both the server and the clients
>> 
>> NEW:
>> the polling mechanism is widely deployed at both servers and clients
>> 
>> (50)
>> 5. "expires" in Response
>> 
>> OLD:
>> would be the majority traffic of the traffic on
>> 
>> NEW:
>> might be the majority of the traffic at
>> 
>> (51)
>> 5. "expires" in Response
>> 
>> OLD:
>> after the change is implemented.
>> 
>> NEW:
>> after the change is implemented. One technique is to start lowering the "expires" value of the affected records the length of the previous "expires" value in advance of the planned change. For example, if the "expires" value of the affected records is three months, then at least three months before the planned change, the "expires" value of the affected records might be lowered to 20 days, and then 15-20 days before the planned change the value might be lowered again, to 10 days or so.
>> 
>> (52)
>> 9. Security Considerations
>> 
>> Delete everything after the first sentence.
>> 
>> --Randall
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit