[Ecrit] Re: Publication has been requested for draft-ietf-ecrit-lost-planned-changes-17

[Randall Gellens <[e-mail]>]

It seems to me that the engineer has a number of suggestions for 
alternate ways of doing things. I think that would have been helpful a 
few years ago. At this point, unless there are substantive technical 
objections (something in the draft won't work or is harmful), I think we 
should advance what we have. If we go back into debating among 
alternative mechanisms, any of which will work, we will never have 
anything.

--Randall

On 13 May 2026, at 14:51, Dan Mongrain wrote:

> Talking (typing) about more substanstive change, here is a comment I
> received from an engineer I asked to review the draft:
>
> "Having an 'expires' attribute in the mapping and the suggested 
> 'expires'
> element in locationValidation will cause confusion.  They should name 
> the
> new element something else.
>
> While I understand the concept is to give an OSP an idea of when to
> revalidate certain records, a simpler approach could be as follows:
>
> 1.  Optionally add an 'expires' element (preferably named something 
> else)
> to the locationValidation section as an extension.  This should also 
> be
> included in the Similar Location draft doc.  This value would the the
> 'Expiration' value from the GIS data.  This gives the clients an idea 
> of
> when to revalidate the record.
> 2.  Change the PlannedChangePoll interface to PollChanges.  This would 
> be a
> new interface, as they stated, where you only pass a date (asOf) into 
> the
> request.  The response is a list of PIDF-LO's that the client can then
> revalidate against.  This endpoint would be optional, primarily 
> enabled
> only on the external LVF server.  LoST Servers can query the 
> DateUpdate
> field in the GIS data model to find what has changed 'asOf' that date. 
>  If
> GIS data authorities aren't maintaining that field, the SI/SDPI could 
> fill
> it in based on the last data upload to the new one, finding the 
> changes and
> updating the field.  There would be no need to know of planned changes 
> in
> advance, because they could query this on a schedule to keep their 
> records
> as up-to-date as possible.
> 3.  If they prefer to know about upcoming data changes, they can add 
> an
> 'effectiveAsOf' element to the new interface. This element could give 
> them
> GIS records that will become effective in the future.
>
> I feel like validating records against roads or address points will 
> also
> introduce complexity.  How is the new interface going to handle this?"
>
> Dan
>
>
> *Dan Mongrain, eng.*Principal Engineer,
> VESTA Solutions
> www.VESTAPublicSafety.com
>
> *[image:
> https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*
>
> *o*:  +1.819.931.2129
> *m*: +1.613.558.0764
> e:   [e-mail] 
> <[e-mail]>
> www.linkedin.com/in/DanMongrain
>
> <https://batchat.motorolasolutions.com/home/ls/community/mic>
>
>
> On Wed, May 13, 2026 at 2:57 PM Brian Rosen <br=
> [e-mail]> wrote:
>
>> I’ve captured this in my working version of an -18.    I wait for 
>> more
>> substantive changes to submit it.
>>
>> Brian
>>
>>
>> On May 13, 2026, at 12:07 PM, Dan Mongrain <dan.mongrain=
>> [e-mail]> wrote:
>>
>> Minor nit, the text talks about a REST/JSON interface whereas the 
>> YAML now
>> returns a XML response. You may want to change the text to REST/XML.
>>
>> Dan
>>
>>
>> *Dan Mongrain, eng.*Principal Engineer,
>> VESTA Solutions
>> www.VESTAPublicSafety.com <http://www.vestapublicsafety.com/>
>>
>> *[image:
>> https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*
>>
>> *o*:  +1.819.931.2129
>> *m*: +1.613.558.0764
>> e:   [e-mail]
>> <[e-mail]>
>> www.linkedin.com/in/DanMongrain
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_DanMongrain&d=DwMFaQ&c=q3cDpHe1hF8lXU5EFjNM_C93KOmcBXCBnhee2v6PYlc&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=QH-LHML933uYxOSSVUV40pBn-yObQhxB4yADXlzmZhN_KRW1ozkyIyXqtnXFFX9G&s=Ypzeksi1eRFNjzaVTSzRTM26j24iYhixR2nPvDhmbL0&e=>
>>
>> <https://batchat.motorolasolutions.com/home/ls/community/mic>
>>
>>
>> On Wed, May 13, 2026 at 11:57 AM Randall Gellens via Datatracker <
>> [e-mail]> wrote:
>>
>>> Randall Gellens has requested publication of
>>> draft-ietf-ecrit-lost-planned-changes-17 as Proposed Standard on 
>>> behalf of
>>> the ECRIT working group.
>>>
>>> Please verify the document's state at
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Decrit-2Dlost-2Dplanned-2Dchanges_&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_C93KOmcBXCBnhee2v6PYlc&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=ghNwahXYEcifXI4zdrcqNC5iyELyYuVULRUgXS8GcyfUf36NeesDrIYRMi2F5AbU&s=e-psyDd5HmroNm6hqf7eMMgFVFdQmn9L5VVSsbqQrv8&e=
>>>
>>>
>>> _______________________________________________
>>> Ecrit mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>> *For more information on how and why we collect your personal 
>> information,
>> please visit our Privacy Policy
>> <https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement> 
>> .*
>> _______________________________________________
>> Ecrit mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>>
>
> -- 
>
>
> *For more information on how and why we collect your personal
> information, please visit our Privacy Policy
> <https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement> 
> .*