Subject: [Ecrit] Comments on [draft-ietf-ecrit-framework-00.txt]

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 11 Jan 2007 10:57:52 -0500

I reviewed this document from the perspective of an employee of a major service provider. Nonetheless, these opinions are mine, as an individual.

I think the overall framework here is reasonable and do-able, and I support this effort. I also understand that this document is incomplete and not ready for publication, and it will continue to be improved upon.

As a general comment, I had to review phonebcp in conjunction with this framework, because there are so many references to it. I realize phonebcp isn't an ecrit document, but I would recommend it be included on the service provider review page. It's highly integral to understanding the overall architecture.

Specific comments:
------------------------------
The definition of ESRP in ecrit requirements seems different than the definition of ESRP in the NENA i3 Functional and Interface Standards. The ecrit requirements and the usage of the term in "framework" seem to suggest that the ESRP could be in the VSP (voice provider) network, since proxies in the VSP network may also do LoST queries. It's not clear that the ESRP expects to get a different LoST response than the endpoint. The NENA doc says that the ESRP is an entry point to a group of PSAPs, and implies that it is the thing that gets routed to by the uri returned by the SIP device's LoST query. Is there something we can do so ESRP means the same thing in both places? I think the NENA usage is what's intended, and the query for routing info done by the ESRP returns different and more detailed routing info than the one done by the SIP end device. The SIP device LoST query leads to the ESRP, and the ESRP query leads to the PSAP. It's also possible for the VSP proxy to do LoST queries, but that doesn't make it an ESRP. A VSP proxy's LoST query would return the same uri as the SIP device's query.
ecrit requirements: 
Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call routing support entity that invokes the location-to-PSAP URI mapping, to return either the URI for the appropriate PSAP, or the URI for another ESRP. (In a SIP system, the ESRP would typically be a SIP proxy, but may also be a back-to-back user agent (B2BUA)). 
NENA: 
Emergency Services Routing Proxy (ESRP) - This ESRP is a routing proxy that acts on behalf of a group of PSAPs, to provide intermediate or final routing to the PSAP, based on the caller's location. This function is not identified explicitly in the i3 functional architecture, but has been discussed in industry presentations and the concept is included in Framework for Emergency Calling in Internet Multimedia <http://www.ietf.org/internet-drafts/draft-rosen-ecrit-framework-00.txt> [3]. The ESRP function is included in the example physical architecture.

Section 2, 3rd full paragraph on Page 6
The term "master-slave" is considered politically incorrect by many governmental bodies in the US. I recommend using other terms to describe these protocols.

Section 3, Figure 1
Needs descriptive text. What do the numbers mean? Boxes also need definition, although they're defined in the Figure 2 description. This is all just editorial, though. 

Bullet 2 (of Figure 2 description)
What is meant by "local domain"? I usually consider my "local domain" to be the domain of my home router, or the domain of my ISP (if my router has no domain). But SIP registration uses a SIP domain, which I don't see as overly "local", since the registration server could be 1000 miles away, or more. Could this maybe be worded something like  "...for Alice's UA to register with. Most SIP UAs will register with a server, so it will be a common scenario for UAs that make emergency calls to be registered with a server."

Bullet 3 [editorial]: change "initiated" to "initiates"

Paragraph after the bullets
"...UA ... has location configured within her UA when her UA boots..." Is this meant to describe the case where the UA gets location configuration as part of its boot process, such as DHCP or L7 CP? Or does it imply a statically stored location which the UA finds and uses during its boot process? This wasn't clear to me. In general, I think there are 3 basic ways the UA could be configured: (1) a saved manually entered location, (2) location manually entered after it boots, (3) receives a location from the network. The location from the network could be a measured location, or it could be based on knowing the physical locations of network termination points. This sentence doesn't convey that to me.

Next paragraph, that starts with "Some time..."
[Editorial]: change "initiated" to "initiates"

Section 6.3
2nd paragraph: "XRef" should probably be [phonebcp]? If it is, then the 3rd to last sentence and the last sentence would be redundant. Note that these guidelines for dealing with multiple locations are not in phonebcp at this time. I'll make this comment against phonebcp.

3rd paragraph
[editorial] end of the paragraph "...and ask the caller with." doesn't make sense.

Section 5.4
[editorial] 2 instances where "can" needs to be "can be"

Section 5.8
I recommend changing "...to ensure that phone billing records correspond to valid..." to
"...to ensure that the service addresses in phone billing records correspond to valid..."

Section 5.9
What is CMTS?
Naturally, "(how?)" needs to be resolved.

Section 6
Paragraph at the end of page 20. 
I had questions here as to whether this VSP proxy would be an ESRP, based on the ecrit requirements definition and the usage of that term in this document. I'm hoping it would not be an ESRP.

Section 7
I'm not sure how practical persistent TLS connection are for large VSPs, given that they may have to connect to thousands of PSAPs.

Section 9
Recommend several references to phonebcp in this section, since phonebcp specifically discusses where these IDs are placed in the SIP message.

Section 11
I would slightly expand this section to also mention the disabling of calling features. For example, change the header and add a sentence like "The disabling of other call features, such as call waiting, is also discussed in phonebcp.

Barbara Stark
BellSouth Science & Technology (a recently acquired part of AT&T)

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624

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