Subject: [Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-changes-04

From: "Randall Gellens" <[email-masked]>
Date: Mon, 23 Aug 2021 15:13:00 -0700

The list server has too aggressive editing, so I'm resending this 
message with the attachments changed to links.

(1) Should the Time to Live information in a validation response be an 
attribute rather than an element?  Logically, it seems more an attribute 
of the response, and also it mirrors the 'expires' attribute on which it 
is modeled.

(2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? 
('AsOf' should be part of the <plannedChange> element but looks like 
maybe it is part of the response, while 'invalidAsOf' is part of 
<plannedChange>).

(3) I'm not sure that "The server MUST have policy that limits use of 
this mechanism by a given client" is warranted; I think using "SHOULD" 
is more easily justified.

I have a number of suggested edits for clarification or language.  
Linked are four files:

The XML uploaded by Brian, with my edits.
draft-ietf-ecrit-lost-planned-changes-04-rg.xml
https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-04-rg.xml

The TXT generated from the XML with my edits.
draft-ietf-ecrit-lost-planned-changes-04-rg.txt
https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-04-rg.txt

An IETF tools diff showing my edits to the TXT, side by side.
Diff-txt.html
https://turing.pensive.org/ecrit/Diff-txt.html

An IETF tools diff showing my edits to the XML, side by side.
Diff-xml.html
https://turing.pensive.org/ecrit/Diff-xml.html

--Randall

---

From: "Caron, Guy" <[email-masked]>
Date: Tue, 24 Aug 2021 19:40:08 +0000

I can't get securely to these resources (NET::ERR_SSL_OBSOLETE_VERSION), perhaps because the web site is using TLS 1.0 or 1.1?

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Randall Gellens
Envoyé : 23 août 2021 18:13
À : [email-masked]
Objet : [EXT][Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-changes-04

The list server has too aggressive editing, so I'm resending this message with the attachments changed to links.

(1) Should the Time to Live information in a validation response be an attribute rather than an element?  Logically, it seems more an attribute of the response, and also it mirrors the 'expires' attribute on which it is modeled.

(2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? 
('AsOf' should be part of the <plannedChange> element but looks like maybe it is part of the response, while 'invalidAsOf' is part of <plannedChange>).

(3) I'm not sure that "The server MUST have policy that limits use of this mechanism by a given client" is warranted; I think using "SHOULD" 
is more easily justified.

--Randall

_______________________________________________
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:21:22 -0400

I’m getting the same response.  I can bypass it, but your server needs an update!

Comments

The changes to the abstract and introduction lose the point that you can ask for validation AsOf some date independent of whether you supply a URI to be notified of a change.
The draft adds two related, but independent capabilities.

In the intro, you reworded: "that is retained by the server associated “ to: "may retain and may associate”.  I think that confuses more than it helps.  Among other things that edit allows it to not do either.  The extension may not be implemented at all, but if it implements it, it may retain (because it has limits on how many/uniqueness/etc), but it always “associates”.

The same problem occurs with the edits in Section 3.

I’m okay with your other suggested edits.

Brian

> On Aug 24, 2021, at 3:40 PM, Caron, Guy <g.caron=[email-masked]> wrote:
>

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 24 Aug 2021 14:38:22 -0700

> I’m getting the same response.  I can bypass it, but your server 

[rg] Sorry about that.  I sent the files in the response to Guy just 
now.

>
> Comments
>
> The changes to the abstract and introduction lose the point that you 
> can ask for validation AsOf some date independent of whether you 
> supply a URI to be notified of a change.

[rg] You're referring to this:

    This
    extension adds two elements to the <findService> request: A URI that
    the LoST server can use to inform the LoST client (e.g., a Location
    Information Server [LIS]) that previously valid locations will be
    invalid after a planned change date, and a date that allows the LoST
    client to request that the server perform validation as of the date
    specified.

[rg] How about adding "These two elements can be used independently" at 
the end, or just add "independent" between "two" and "elements"?

> In the intro, you reworded: "that is retained by the server associated 
> “ to: "may retain and may associate”.  I think that confuses more 
> than it helps.  Among other things that edit allows it to not do 
> either.  The extension may not be implemented at all, but if it 
> implements it, it may retain (because it has limits on how 
> many/uniqueness/etc), but it always “associates”.
>

[rg] That came from my misunderstanding of your intent.  Please see my 
email from last night about the need for new explanatory text to help a 
reader understand the intent, and new normative text regarding what a 
LoST server can do if it implements this.

> I’m okay with your other suggested edits.

[rg Thanks.

> Brian
>
>
>
>> On Aug 24, 2021, at 3:40 PM, Caron, Guy 
>> <g.caron=[email-masked]> wrote:
>>
>> I can't get securely to these resources 
>> (NET::ERR_SSL_OBSOLETE_VERSION), perhaps because the web site is 
>> using TLS 1.0 or 1.1?
>>
>> Guy
>>
>> (1) Should the Time to Live information in a validation response be 
>> an attribute rather than an element?  Logically, it seems more an 
>> attribute of the response, and also it mirrors the 'expires' 
>> attribute on which it is modeled.
>>
>> External Email: Please use caution when opening links and attachments 
>> / Courriel externe: Soyez prudent avec les liens et documents joints
>>

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 24 Aug 2021 14:30:53 -0700

My apologies.  It is pretty out of date.  Attached are the files.

--Randall

On 24 Aug 2021, at 12:40, Caron, Guy wrote:

> (NET::ERR_SSL_OBSOLETE_VERSION), perhaps because the web site is using 
> TLS 1.0 or 1.1?
>
> Guy
>
> attribute rather than an element?  Logically, it seems more an 
> attribute of the response, and also it mirrors the 'expires' attribute 
> on which it is modeled.
>