Subject: [Ecrit] draft-ietf-ecrit-additional-data

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Nov 2010 15:52:27 -0700

I wonder about how one would authenticate all this data - I'm less worried about information that a human operator decide to apply judgement to but I'm worried about data that causes automated policy to happen. For example, if a thief knows that if my alarm system calls the the center 10 times in a row in a bogus way, it will get blocked on future calls, what stops the thief from impersonating however my alarm system identifies itself, makes the calls,  and thus rendering the alarm system blocked. 

A few small comments about some of the data inside ...

Overall, it seems like a grab bag of everything we could find vs what would be truly useful in anon trivial number of corner cases. 

Section 3.7 - these categories seem overlapping and confused in that they measure different things. For example. Something could be both a prison phone and a POTS. 

I think it would be much better to focus on what the relevant attributes for the PSAP are and then have individual capabilities. I can see it is useful to know if this is two way voice or not. I can see it would useful to know if the phone has a high risk of prank calls or not based on it's the level of public accessibility. I'm having a harder time seeing the need to know if a phone is multiline or not. My cell phone does two calls at once, is it multiline? 

Similarly with table 3.8 - focus on the attributes that are important to the PSAP. I can't even imagine which of these categories an iphone would fall into. It's funny, the text you have in your "reason for need" look Luke fine attributes but don't map to the table in the slightest. 

I'm pretty skeptical that this is the right place to transfer all the unique device identifiers.  It seems like theses would better be handled in other places. 

3.14 - Isn't call-id on the PSTN today all the proof you need that this is an awful design for restricting call-id. "Here is the secret data but please don't look at it" 

And uh, about that security section..... I have full confidence that the authors can easily make substantial improvements to that section :-)

---

From: Brian Rosen <[email-masked]>
Date: Sun, 7 Nov 2010 21:11:46 -0500

Thanks for looking at this. See inline for some of my responses

> I wonder about how one would authenticate all this data - I'm less worried about information that a human operator decide to apply judgement to but I'm worried about data that causes automated poli…

Generally, the more common service providers will have credentials that would allow the PSAP to have some confidence that they know whom they are talking to, but generally, this is considered untrustworthly information.
> Overall, it seems like a grab bag of everything we could find vs what would be truly useful in anon trivial number of corner cases. 
Actually, nearly all of it has a direct analog in the current U.S. system.  They don't get all of it all the time, and the form of the data is very different, but the way these items were constructed was looking at the current system and asking "what is the equivalent in the IP world?".  That isn't entirely true (device characteristics for example).
> Section 3.7 - these categories seem overlapping and confused in that they measure different things. For example. Something could be both a prison phone and a POTS. 
We tried pretty hard to figure out what would be useful.  We know that there will be overlaps, and new services.  It's useful to know this kind of data, and perhaps some advice would be useful.  In your example, we would want to know it's a prison phone much more than POTS.

> I think it would be much better to focus on what the relevant attributes for the PSAP are and then have individual capabilities. I can see it is useful to know if this is two way voice or not. I ca…
I think yes.  Multiline tells us the phone could go on hold.  If yours can, then we probably want to know.

Attributes may be a good idea.  A list of attributes where you can send a set.  I'll work on that and see where it gets us.

> Similarly with table 3.8 - focus on the attributes that are important to the PSAP. I can't even imagine which of these categories an iphone would fall into. It's funny, the text you have in your "r…
Yeah, the reason for need doesn't work right here.  See above on attributes.
> I'm pretty skeptical that this is the right place to transfer all the unique device identifiers.  It seems like theses would better be handled in other places. 
Maybe, but suggest a better place.  The point was that all the info a device or service provider knows that is not in the signaling goes in this one place.

> 3.14 - Isn't call-id on the PSTN today all the proof you need that this is an awful design for restricting call-id. "Here is the secret data but please don't look at it" 
We get this now.   It's mostly for downstream systems; the emergency services don't restrict anything, at least in the U.S. 
> And uh, about that security section..... I have full confidence that the authors can easily make substantial improvements to that section :-)
Uh, yeah, we can do that.
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit