Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt

From: [email-masked]
Date: Thu, 19 Aug 2021 17:27:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies WG of the IETF.

        Title           : Validation of Locations Around a Planned Change
        Author          : Brian Rosen
	Filename        : draft-ietf-ecrit-lost-planned-changes-04.txt
	Pages           : 19
	Date            : 2021-08-19

Abstract:
   This document defines an extension to LoST (RFC5222) that allows a
   planned change to the data in the LoST server to occur.  Records that
   previously were valid will become invalid at a date in the future,
   and new locations will become valid after the date.  The extension
   adds two elements to the <findservice> request: A URI to be used to
   inform the LIS that previously valid locations will be invalid after
   the planned change date, and add a date which requests the server to
   perform validation as of the date specified.  It also adds an
   optional Time-To-Live element to the response, which informs clients
   about the current expected lifetime of the validation.  This document
   also provides a conventional XML schema for LoST, as backwards
   compatible alternative to the RelaxNG schema in RFC5222

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-lost-planned-changes-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-lost-planned-changes-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Rosen <[email-masked]>
Date: Thu, 19 Aug 2021 20:34:54 -0400

This too, finally, is redone.  I believe all comments were addressed.  XML should be checked, but I THINK it’s right now.  There is a bit of new text that explains the LoST server doesn’t have to save the Location Information that was sent in the findService request.  That means that the notification, if requested, will be sent for any change, which means the client could get a notification to revalidate only to find they got the same result.  

I did specify the Content-Type as application/xml instead of defining a new media type.  I think that’s okay, comments welcome.

Brian

> On Aug 19, 2021, at 8:27 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 21 Aug 2021 19:33:59 +0200

Brian,

I think this one looks good and mature.

I have only found a few editorials and traditional xml mistakes ( if I 
got it right ):

1. In Abstract, "<findservice>" s.b. "<findService>"

2. In Abstract, in the middle, ", and add a date" s.b. ", and a date"

3. In Abstract: Full stop missing at the end.

4.  In 1. Introduction, second line, "<findservice>" s.b. "<findService>"

5.  In 1. Introduction, third paragraph: Full stop missing at the end.

6.  In 4. second paragraph, second line:  findService s.b. <findService>

7.  In 7. first line "The Relax" s.b. "the Relax"

8.  In 8. In the "plannedChange" element, "invalidAsOf"  got its leading 
quoutation mark changed to a curly leading double quote instead of a 
straight double quote. Was that intentional, and is that safe, or should 
you return to using straight double quote?

9.  In 8. Section 8 contains extensions to the schema presented in 
section 7. Is the editing instruction notations formal enough to 
reliably create the extended schema correctly. Would it not be safer, 
and more convenient for developers if you provided the completed schema, 
with easily found comments around the extensions, so that anyone 
interested in creating the schema in section 7 could do that?
Please explain why it is the schema in section 7 that is provided as a 
complete schema and 8 just as editing instructions and not the other way 
around, when it is the schema resulting from section 8 that is the 
purpose of the specification.

10. In 9.  I think the following two lines are missing before the last line:
        </xs:complexType>
    </xs:element>

Regards

Gunnar

-- 
Gunnar Hellström
GHAccess
[email-masked]

Den 2021-08-20 kl. 02:34, skrev Brian Rosen:
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 Aug 2021 15:30:57 -0400

Thanks for the close read, and especially thanks for looking at the xml.

I will make all of the changes for 1-7.  On #8, it should be a straight quote.  I will fix it.

On 9, that’s the way I’ve usually seen IETF docs use an extension point.  I will make any changes the work group decides here.  One possibility is to tie planned-changes to -similar-location and have the schema in the latter incorporate all the extensions.   This is more xml work for me, and it’s not my strong suit, but I’ll do whatever the WG decides.

I’m clearly not communicating how the mechanism works well enough in the document.  I will have to try harder.

The extension to findService offers an (optional) URI to be passed in the request.  The server stashes the URI with the record.  If a change in the record occurs later, the server does a POST to the URI using the object defined in Section 7.  That object is not related to the rest of the LoST schemas because it’s not part of the LoST protocol, but rather a side effect of one aspect of the protocol.  When the LoST server does that POST, it’s actually a client to the LoST client’s web service.

I will fix - 10.  I must have made a late editing error.

Brian

> On Aug 21, 2021, at 1:33 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> Brian,
> 
> I have only found a few editorials and traditional xml mistakes ( if I got it right ):
> 
> 8.  In 8. In the "plannedChange" element, "invalidAsOf"  got its leading quoutation mark changed to a curly leading double quote instead of a straight double quote. Was that intentional, and is that safe, or should you return to using straight double quote?
> 
> 9.  In 8. Section 8 contains extensions to the schema presented in section 7. Is the editing instruction notations formal enough to reliably create the extended schema correctly. Would it not be safer, and more convenient for developers if you provided the completed schema, with easily found comments around the extensions, so that anyone interested in creating the schema in section 7 could do that?
> Please explain why it is the schema in section 7 that is provided as a complete schema and 8 just as editing instructions and not the other way around, when it is the schema resulting from section 8 that is the purpose of the specification.
>

---

From: "Caron, Guy" <[email-masked]>
Date: Mon, 23 Aug 2021 20:14:27 +0000

Hi all,

I did review the noted draft and have substantive comments that I will post under distinct object lines.

Thanks for updating this long awaiting draft.

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Brian Rosen
Envoyé : 19 août 2021 20:35
À : ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt

Brian

> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Brian Rosen <[email-masked]>
Date: Tue, 24 Aug 2021 16:26:15 -0400

I’ll fix 1-8 and 10.

The reason I did the schemas the way I did them was to provide an authoritative xml schema to an implementation that doesn’t (yet) implement the planned-changes extensions.  Lots of implementations use non authoritative schemas they either built themselves or got from somewhere else.   This allows those implementations to switch to this authoritative schema.

The extensions work the way all the other extensions to LoST have been specified.

Brian