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

["Murray S. Kucherawy" <[e-mail]>]

Ping?

On Wed, Nov 8, 2023 at 9:44 AM Brian Rosen <[e-mail]> wrote:

> 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]> 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)
>>
>>    1. Introduction
>>
>> OLD:
>> the LIS operator
>>
>> NEW:
>> a LIS operator
>>
>> (6)
>>
>>    1. Introduction
>>
>> OLD:
>> the server has no
>>
>> NEW:
>> a server has no
>>
>> (7)
>>
>>    1. Introduction
>>
>> OLD:
>> to obtain from the LoST server
>>
>> NEW:
>> to obtain from a LoST server
>>
>> (8)
>>
>>    1. Introduction
>>
>> OLD:
>> in the order they were made
>>
>> NEW:
>> in the correct order
>>
>> (9)
>>
>>    1. Introduction
>>
>> OLD:
>> allows the client to poll the server
>>
>> NEW:
>> allows a client to poll a server
>>
>> (10)
>>
>>    1. Introduction
>>
>> OLD:
>> response to the poll
>>
>> NEW:
>> response to a poll
>>
>> (11)
>>
>>    1. Introduction
>>
>> OLD:
>> will be used by the client
>>
>> NEW:
>> is used by the client
>>
>> (12)
>>
>>    1. Introduction
>>
>> OLD:
>> change, the LIS may use
>>
>> change, a LIS may use
>>
>> (13)
>>
>>    1. Introduction
>>
>> OLD:
>> In its response, the LoST server
>>
>> NEW:
>> In its response, a LoST server
>>
>> (14)
>>
>>    1. Introduction
>>
>> OLD:
>> include a new "expires"
>>
>> NEW:
>> include the new "expires"
>>
>> (15)
>>
>>    1. 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)
>>
>>    1. 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)
>>
>>    1. Introduction
>>
>> OLD:
>> allows the LIS
>>
>> NEW:
>> allows a LIS
>>
>> (17)
>>
>>    1. Introduction
>>
>> OLD:
>> the data in the LIS
>>
>> NEW:
>> the data in a LIS
>>
>> (18)
>>
>>    1. Introduction
>>
>> OLD:
>> However, the LoST server
>>
>> NEW:
>> However, LoST servers
>>
>> (19)
>>
>>    1. Introduction
>>
>> OLD:
>> adds a "expires"
>>
>> NEW:
>> adds an "expires"
>>
>> (20)
>>
>>    1. 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]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>
>