Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation?
Randall Gellens <rg+ietf@randy.pensive.org> Mon, 23 August 2021 23:17 UTC
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D143A089B for <ecrit@ietfa.amsl.com>; Mon, 23 Aug 2021 16:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COTBUivpIIWZ for <ecrit@ietfa.amsl.com>; Mon, 23 Aug 2021 16:17:51 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4963A08A5 for <ecrit@ietf.org>; Mon, 23 Aug 2021 16:17:51 -0700 (PDT)
Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:39:48 -0700
From: Randall Gellens <rg+ietf@randy.pensive.org>
To: "Caron, Guy" <g.caron@bell.ca>
Cc: Brian Rosen <br@brianrosen.net>, ecrit@ietf.org
Date: Mon, 23 Aug 2021 15:39:47 -0700
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <2B6FB05F-6A89-4680-893F-06584E7EFAF8@randy.pensive.org>
In-Reply-To: <794ed22ebe3e48cdb0e72cf3f0a91429@bell.ca>
References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <F0AC030F-C6B8-4A2B-ADC3-7E69D0C18FBB@brianrosen.net> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> <cd5677dfaa91450f899a56764c18809a@bell.ca> <64E97C26-36C8-4024-89E3-E23379E614B5@randy.pensive.org> <794ed22ebe3e48cdb0e72cf3f0a91429@bell.ca>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_136AFBB1-4771-4A9C-AC30-931CB95394FF_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"HTML":[758, 45562], "plain":[427, 6875], "uuid":"7222DF3E-5E3D-4253-89D1-F102649DB7AE"}]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/YCj4N-UregK9_hEnRmOkcLeyV98>
Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation?
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Emergency Context Resolution with Internet Technologies <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Aug 2021 23:17:58 -0000
I'm trying to understand the harm of allowing a client to request notification whether it is asking for validation or not. We already say that server policy can refuse to store a URI for any reason, so a server could prohibit this if it wants to (e.g., to save resources). If a server is OK providing this server, what do we care? It doesn't harm interoperability. --Randall On 23 Aug 2021, at 15:34, Caron, Guy wrote: > I’m not concerned about a client that willfully and knowingly asks > for it. > > This whole draft revolves around location validation. I’m not > understanding the pushback here. > > Guy > > De : Randall Gellens <rg+ietf@randy.pensive.org> > Envoyé : 23 août 2021 18:31 > À : Caron, Guy <g.caron@bell.ca> > Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound > to validateLocation? > > > If a client wants to get notified that a location may have become > invalidated, why do we care why or what type of client it is? > > --Randall > > On 23 Aug 2021, at 15:26, Caron, Guy wrote: > > I understand and what I’m suggesting is to be clear about what LoST > clients are expected to do. We do not want a leasy implementation > sending <plannedChange> across the board, don’t we? I think it is > easy and cheep to fix in the draft rather to try to fix > implementations later. > > > > Guy > > > > De : Brian Rosen <br@brianrosen.net<mailto:br@brianrosen.net>> > Envoyé : 23 août 2021 18:14 > À : Caron, Guy <g.caron@bell.ca<mailto:g.caron@bell.ca>> > Cc : ecrit@ietf.org<mailto:ecrit@ietf.org> > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > Sure, PSAPs could be a LoST client for example. A routing proxy can > be a LoST client. But they wouldn’t ask to store the URI. You have > to ask for it to get the notification. > > > > Brian > > > > On Aug 23, 2021, at 6:10 PM, Caron, Guy > <g.caron@bell.ca<mailto:g.caron@bell.ca>> wrote: > > > > You miss my point. The LoST client may not be a LIS. If we make it > explicit that only LISes are LoST clients in the context of this > draft, I may not have as strong objections. > > > > Guy > > > > De : Brian Rosen <br@brianrosen.net<mailto:br@brianrosen.net>> > Envoyé : 23 août 2021 18:06 > À : Caron, Guy <g.caron@bell.ca<mailto:g.caron@bell.ca>> > Cc : ecrit@ietf.org<mailto:ecrit@ietf.org> > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > Only if it asked for it, per location. It asked for it, it got it. > > > > It has NOTHING to do with actual calls. It’s just an alternative to > periodic revalidation for records in the LIS. > > > > A more interesting issue is what does a LIS do when it deletes a > record for which a URI is stored in the server. Probably it marks > that URI is OBE. Another possibility is that it stores a new URI that > is a catch-all “ignore me” > > > > Hmmm. I wonder if we should have an explicit delete. Null URI = > delete. > > > > Brian > > > > > > On Aug 23, 2021, at 6:01 PM, Caron, Guy > <g.caron@bell.ca<mailto:g.caron@bell.ca>> wrote: > > > > A LoST client that sends routing requests to the server would receive, > way after calls have been delivered, a notification with a > <locationInvalid> body. What would it do with this? > > > > Makes no sense to me. > > > > Guy > > > > De : Brian Rosen <br@brianrosen.net<mailto:br@brianrosen.net>> > Envoyé : 23 août 2021 17:55 > À : Caron, Guy <g.caron@bell.ca<mailto:g.caron@bell.ca>> > Cc : ecrit@ietf.org<mailto:ecrit@ietf.org> > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > I don’t understand the reasoning on “creating havoc”. I don’t > know why a client would ever do it, but it “works” in that the > server doesn’t have to validate to save the URI. If I client sends > the URI and doesn’t validate, it’s weird, but not wrong. > > > > We can decide to prohibit it. But we don’t really have a > justification. > > > > Brian > > > > > On Aug 23, 2021, at 5:44 PM, Caron, Guy > <g.caron@bell.ca<mailto:g.caron@bell.ca>> wrote: > > > > I agree that accommodating this comment would require deeper XML > changes. > > > > If we do not want to go there, I think the draft should be clear that > there is no usecase for sending <plannedChange> outside of a location > validation request and as such, should normatively recommend not doing > so. > > > > I do not agree that a LoST server receiving <plannedChange> outside of > a location validation request would retain the URI and send > notification if the record changed afterward. I think this would > create havoc on the client’ side. > > > > Thanks, > > > > Guy > > > > De : Brian Rosen <br@brianrosen.net<mailto:br@brianrosen.net>> > Envoyé : 23 août 2021 17:22 > À : Caron, Guy <g.caron@bell.ca<mailto:g.caron@bell.ca>> > Cc : ecrit@ietf.org<mailto:ecrit@ietf.org> > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > validateLocation is an attribute, not an element, so I can’t extend > it. > > > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed” not “what you sent is guaranteed to be > invalid” or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > > > Brian > > > > > > On Aug 23, 2021, at 5:07 PM, Caron, Guy > <g.caron@bell.ca<mailto:g.caron@bell.ca>> wrote: > > > > Not all LoST server implementations perform location validations. When > location validation is requested by the client, it adds the > “validateLocation” attribute to the <findService> element. > > > > So the question is: Should “plannedChange” be bound to > “validateLocation”? > > > > If you believe not, what would be the expected behaviour of a LoST > server receiving a <plannedChange> element outside of a validation > request? > > > > Thanks, > > > > Guy > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org<mailto:Ecrit@ietf.org> > 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
- [Ecrit] lost-planned-changes-04: plannedChange bo… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Brian Rosen
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Brian Rosen
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Brian Rosen
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Brian Rosen
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Caron, Guy
- Re: [Ecrit] lost-planned-changes-04: plannedChang… Randall Gellens