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

[Randall Gellens <[e-mail]>]

I wouldn't expect to hear back from Brian until after the 1st.

--Randall

On 19 Dec 2023, at 14:58, Murray S. Kucherawy wrote:

> 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
>>
>>
>>