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

[Randall Gellens <[e-mail]>]

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