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

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

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
>