Subject: [Ecrit] Ids in LoST

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Aug 2012 15:17:58 -0400

In NENA, we're interested in being able to log queries on the LoST server, and relate them to the call.  There isn't any way to do that - the LoST server doesn't know the  call id or incident id.

Here is a specific use:
We use a LoST server inside our Emergency Services IP network to route to the proper responders based on the location of the caller.  The PSAP queries using LoST and a special service URN to get the URI of the appropriate fire brigade that serves the location of the incident.  The client (the PSAP) and the LoST server both log the query and response, and if the query recurs (because, for example, the call is answered out of area, and the local LoST server isn't authoritative for the incident location), the recursion is logged along the path by each step.

If something goes wrong, we want to be able to search the logger for all events that occurred for a particular call or incident (we have two identifiers, since we can have multiple calls about the same incident).  The problem, of course, is while the PSAP knows the call and incident IDs, the LoST servers don't.  So when they log the query and response, they can't annotate the log record appropriately.  

Most emergency systems have stringent logging requirements like this.

If the LoST server has to recursively query another LoST server, we have essentially the same problem - no way to relate the queries as we trace them through the network.

What would be helpful is to have an id passed in the query which is returned in the response, and also passed on in the recursive query (and thus passed back in the recursive response).

We would like the ID to be typed (that is, we need to know it's a NENA call id), so what we are thinking of is an optional extension to LoST that passes and ID and an id type (which is listed in a registry).  We would like to be able to have more than one.  The server is only asked to include it (or them if it there are more than one of them) in the response, and in any recursive query.

If this seems reasonable, I will write a draft.  If IETF won't, NENA can always do a private extension.  Seems like a generally useful capability.

Example
<id type=nena.call>4547s8gs889</id>

Brian

---

From: Randall Gellens <[email-masked]>
Date: Thu, 30 Aug 2012 13:53:41 -0700

At 3:17 PM -0400 8/30/12, Brian Rosen wrote:

>  What would be helpful is to have an id passed in the query which is 
> returned in the response, and also passed on in the recursive query 
> (and thus passed back in the recursive response).
>
>  We would like the ID to be typed (that is, we need to know it's a 
> NENA call id), so what we are thinking of is an optional extension 
> to LoST that passes and ID and an id type (which is listed in a 
> registry).  We would like to be able to have more than one.  The 
> server is only asked to include it (or them if it there are more 
> than one of them) in the response, and in any recursive query.
>
>  If this seems reasonable, I will write a draft.

This seems both generally useful and harmless.  Useful for the 
specific case Brian described, but also because in general it's 
useful to be able to pass strings around that are only for logging 
(e.g., trace fields in SMTP message format).  Harmless because it's 
an optional field that doesn't alter the protocol and doesn't affect 
behavior.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I have made this letter longer than usual because I lack the
time to make it shorter.                     --Blaise Pascal

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 31 Aug 2012 07:23:45 +0800

I understand why it is wanted. I agree that it is probably useful once you are inside the ESInet, but I understood the current charter to be limited to getting us to the ESInet.
I think that this kind of extension would be better done inside NENA.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, 31 August 2012 5:18 AM
To: [email-masked] Org
Subject: [Ecrit] Ids in LoST

Here is a specific use:

Example

Brian

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit