Subject: [Ecrit] Review of Phone BCP 01

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 6 Aug 2007 22:08:09 -0500

Hi All, in particular James and Brian,

Attached is a marked up word document with my review comments for the
phone BCP. I summarize the high-level points below:

Generally I think that most of the content for this document is there. I
don't think it is a very readable document however, and needs a lot of
editorial work from that perspective. I have provided some comments to
this effect in some places, but it does need more.

I don't think that some of the timing requirements provided in the
document are accurate or achievable. In particular the call completing
in 2 seconds and location provided in a 100ms. I think that we could
borrow from cellular best practice here with more likely achievable
results. This would then align with real-world BCP, rather than some
arbitrarily set target.

I would suggest a reorganization of various sections that provide steps.
Providing a new section header for each element under the UAC
requirements would aid readability no end. This could also be broken up
into sections that describe what the desired behaviour is, and then have
a separate section for legacy or exception cases. Diagrams showing the
flow of steps would also aid the readability of the document.

There are quite a number of requirements in the document that have no
parallels in existing BCP infrastructure and there is little or no
justification for their inclusion in this document. I have highlighted
these in my markup	 

If there are any comments you want discuss please let me know.

Cheers
James

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Aug 2007 14:50:39 +0200

Hi James,

thanks for your review.

I would like to comment on a few selected items:

* We should not introduce new terminology in the document. We already 
have a good document that defines the terms.

* I would not go into the details of describing one example message flow 
in the introduction. This stuff is supposed to be in the framework 
document.

*  I really question the usefulness of periodically requesting location 
information just to have it ready during an emergency call situation. 
The reason is:
 - Load on Location Servers
 - Drains the battery of mobile devices
 - Generates a lot of traffic

* I also agree that the timing requirements come out of nowhere and 
should be either justified (with a reference to a document that supports 
it) or removed.

Ciao
Hannes

> ------------------------------------------------------------------------
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Aug 2007 09:13:00 -0400

The load on the system and the battery drain are addressable by changing the
interval.  It could even be adaptive; increase the interval if the location
is close to the same value, decrease it if the location is changing.  I
don't mind the interval being long enough to keep the load small.

The call completion requirements come from NENA.  NENA i3 Technical
Requirements Document, NENA 08-0751: 

"Signaling 1400-0100 Call setup time (dialing of last digit to ring at the
PSAP), under expected peak load shall be less than 2 seconds.  If CAMA or
CAMA-like signaling is in the path, then an additional 7 seconds is
permitted. "

This document was shared with ecrit.  There is no CAMA or CAMA-like dialing
in the actual NENA i3 solution.

Brian   

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, August 27, 2007 8:51 AM
> To: Winterbottom, James
> Cc: ECRIT
> Subject: Re: [Ecrit] Review of Phone BCP 01
> 
> Hi James,
> 
> thanks for your review.
> 
> ------------------------
> ------------------------

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 27 Aug 2007 15:16:32 +0200

Hi Brian, 

> don't mind the interval being long enough to keep the load small.

It is OK for me to say that this is policy dependent with the text above
as example. 

> CAMA-like signaling is in the path, then an additional 7 seconds is

Thanks for the reference. I think we should add a pointer to "NENA
08-0751" to the draft and the respective section. 

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 28 Aug 2007 02:06:33 -0500

Hi Hannes,

Comments inline.

Cheers
James

> Sent: Monday, 27 August 2007 10:51 PM
> To: Winterbottom, James
> Cc: ECRIT
[AJW] Did I suggest new terms? I thought what I was suggesting was to
say where these terms are defined rather than inlining the definitions
in the document.  For example The introduction currently says:
"Here, an emergency call refers to a communications session established
by a
   user to a "Public Safety Answering Point" (PSAP) which is a call
   center established by response agencies to accept emergency calls."

What I was trying to suggest was that the document have a normative
terms section that says is PSAP is reused as in XXX, blah is reused in
XXXX. Then the terms don't need to be spelt out in the text.

> in the introduction. This stuff is supposed to be in the framework

[AJW] I will use the argument that is always used on me. This document
must be able to stand on its own. I think its legs are less stable
without an example when its "framework" is taken away... ;)

> should be either justified (with a reference to a document that
supports

[AJW] I saw from Brian that these requirements apparently came from
NENA. I would like to understand how the NENA i3 group arrived at these
requirements given they seem to be at odds with experience in the
cellular calling world. I would like to see more latitude given to the
time it takes to determine location at call time if we are to avoid
going backwards from current best practice.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 28 Aug 2007 09:11:38 +0200

Hi James,

> XXXX. Then the terms don't need to be spelt out in the text.
Right. We don't want to have the terminology inline in the document.

>> * I would not go into the details of describing one example message
>>     
> flow
>   

I believe that this document does not make a lot of sense without the 
framework.

>  
>   
>> *  I really question the usefulness of periodically requesting
>>     
> location
>   
>> should be either justified (with a reference to a document that
>>     
> supports
>   
>> it) or removed.
>>
>>     
>
OK. Brian is the right one to respond to this question.

Ciao
Hannes

>>> Attached is a marked up word document with my review comments for
>>>       
> the
>   
>>> Generally I think that most of the content for this document is
>>>       
> there. I
>   
>>> don't think it is a very readable document however, and needs a lot
>>>       
> of
>   
>>> editorial work from that perspective. I have provided some comments
>>>       
> to
>   
>>> document are accurate or achievable. In particular the call
>>>       
> completing
>   
>>> I would suggest a reorganization of various sections that provide
>>>       
> steps.
>   
>>> requirements would aid readability no end. This could also be broken
>>>       
> up
>   
>>> into sections that describe what the desired behaviour is, and then
>>>       
> have
>   
>>> a separate section for legacy or exception cases. Diagrams showing
>>>       
> the
>   
>>> There are quite a number of requirements in the document that have
>>>       
> no
>   
>>> justification for their inclusion in this document. I have
>>>       
> highlighted
>   
>>> these in my markup
>>>