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

From: "Brian Rosen" <[email-masked]>
Date: Sun, 4 Mar 2007 19:43:37 -0500

I'm finally editing -framework.   See my responses inline

  _____  

From: Stark, Barbara [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 10:58 AM
To: ECRIT
Subject: [Ecrit] Comments on [draft-ietf-ecrit-framework-00.txt]

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.

<br>I agree.  -framework (which is informative and big picture) refers to
-phonebcp (which is "normative" in the sense that a BCP specifies behavior)
and -phonebcp tries to mechanize what -framework says.  I don't see any
request to change text in either document here, but if you have suggestions,
they would be welcome

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.

<br>I have modified the text to make it more clear that an "ESRP" is
something in the emergency services domain.  I just call a proxy that may
provide some emergency call services a "sip proxy server".  In the IMS
world, that would be an "E-CSCF", but if I had my druthers, it would be the
endpoing doing the work, with the regular outbound proxy (the first proxy
that gets a call) doing backstop for the endpoint not doing it.  We're not
going to get into the NENA i3 work in this document.

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.

<br> fixed

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. 

<br>the numbers are defined in the text as the message numbers.  I have
significantly reworked this part.  Would you look at it again and tell me if
you think I've dealt with this problems?

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."

<br> fixed

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

<br>I reworded text here, and "initiated is gone

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.

<br>the text has been edited heavily.  Is it more clear now?

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

<br>fixed

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.

<br> -pidf-lo-profile discusses the various ways you get multiple location
things and what they should be used for.  Conveyance adds yet another
dimension to that.  -phonebcp needs text to advise.  I fixed the reference
here to -pidf-lo-profile, and added "additional" to "guidance".

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

<br>fixed

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

<br> fixed

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. 

<br>defined as Cable Modem Termination system.  We need a discussion on how
to mark default locations. 

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.

<br>It's not, and the adjusted text above should make that clear

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.

<br>I don't think that is a problem.  In practical terms in the U.S. the VSP
will connect to 50 state level ESRPs, which will be next hop for them.

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

<br>done

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.

<br>done

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