Subject: RE: [Ecrit] ECRIT requirements: R5 reprise

From: "Roger Marshall" <[email-masked]>
Date: Mon, 19 Sep 2005 12:56:55 -0700

Yes, I've included/embedded the thread of Henning's comments to Ted's
last R5 contribution down in the body.  Based on this, I've reformed the
requirement, taking Henning's comment on "call flow" into account, and
breaking the paragraph into two parts, a requirement and a motivation,
since that seemed to make sense to do so.

Proposal: Change R5 Requirement 

From:

R5.  Minimum Connectivity:  An emergency call SHOULD succeed as long
as there is a working network path between the caller and the
PSAP.  In particular, reliance during call set-up and calls on
entities and network paths that are located elsewhere should be
minimized.

Example: A caller in New York who needs to contact a PSAP in the
same city shouldn't have to get information from some entity in
Texas to make that call, as the call would then fail if the New
York to Texas path is unavailable.  (To avoid this, the caller
could, for example, have cached mapping information, use a local
server that has the necessary information, or use other mechanisms
to avoid such off-path dependencies.)

To: 

R5. Minimum Connectivity

The ability to discover the correct PSAP, SHOULD NOT require a 
level of connectivity substantially beyond that which would be 
needed to contact that PSAP.  

Motivation: It is not required that the servers used for 
discovery be on-path to the media and signaling path, but 
their reachability should be a strong consideration in 
devising deployment strategies.

Does this capture what we want to say about this topic?

 -Roger.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Henning Schulzrinne
>Sent: Thursday, June 30, 2005 6:56 PM
>To: Ted Hardie
>Cc: [email-masked]
>Subject: Re: [Ecrit] R5
>
>Ted Hardie wrote:
>> Henning's proposal is:
>> 
>> 
>>>R5.  Minimum Connectivity
>>>
>>>An emergency call should succeed as long as there is a 
>working network path between the caller and the PSAP. In 
>particular, reliance during call set-up and calls on entities 
>and network paths that are located elsewhere should be minimized.
>>>
>>>Example: A caller in New York who needs to contact a PSAP in 
>the same 
>>>city shouldn't have to get information from some entity in Texas to 
>>>make that call, as the call would then fail if the New York to Texas 
>>>path is unavailable. (To avoid this, the caller could, for example, 
>>>have cached mapping information, use a local server that has the 
>>>necessary information, or use other mechanisms to avoid such 
>off-path 
>>>dependencies.)
>>>
>>>I hope this is clearer.
>> 
>> 
>> I think "working network path between the caller and the PSAP" isn't 
>> clear enough.  Do you mean only that there is IP 
>connectivity between 
>> the terminal and the PSAP's IP address?  Taking SIP as the presumed 
>> contact method for
>
>
>> a moment, would that imply that the terminal should be able 
>to connect 
>> to the PSAP, even if its normal proxy is unavailable and the 
>proxy for 
>> the PSAP is also unavailable?  Or does the "working network path" 
>> imply that the proxies configured for these are also up and 
>available?
>
>Yes, "working network path" = "current IP connectivity" + 
>"ability to route SIP calls via outbound proxy [if necessary] 
>and PSAP proxy". The basic rule is simple:
>
>"The look-up process should not add any additional 
>network-related failure modes. In other words, if a caller 
>knew the PSAP signaling address and can reach it via signaling 
>and media, the usage of a mapping mechanism should not 
>interfere with that reachability if network connectivity to 
>parts of the mapping service is temporarily impaired."
>
>
>> 
>> I'd also strongly suggest that "located elsewhere" mixes up network 
>> topology with geography, which is one of our constant sources of 
>> confusion.  Can you recast this in terms of network topology?
>
>Agreed. Located elsewhere ==> maybe "located in parts of the 
>network that are neither on the signaling nor media path from 
>the caller to the PSAP". It's a bit longer...
>
>> 
>> Something like:
>> 
>> R.5.
>> 
>> The ability to discover the correct PSAP should not require 
>a level of 
>> connectivity substantially beyond that which would be needed to 
>> contact that PSAP.  It is not required that the servers used for 
>> discovery be on-path to the call flow, but their reachability should 
>> be a strong consideration in devising deployment strategies.
>
>This is ok, although "call flow" is a bit mushy (and means 
>something rather different in the SIP community, if you look 
>at documents titled "call flows"). One could simply say "media 
>and signaling path" instead. 
>I believe these terms are widely understood, at least on the 
>VoIP side of the world.
>
>
>
>> 
>> 
>> 			regards,
>> 				Ted

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tom-PT Taylor
Sent: Monday, September 19, 2005 11:46 AM
To: Andrew Newton
Cc: [email-masked]
Subject: Re: [Ecrit] ECRIT requirements: R5 reprise

I'll buy your tweak, and I do apologize: it was Ted, not Marc.

Andrew Newton wrote:
> 
> On Sep 19, 2005, at 1:52 PM, Tom-PT Taylor wrote:
> 
>> We had a fair-sized discussion on R5 at the beginning of July.   Marc

>> formulated an alternative statement that seemed to hold  promise.  
>> Andrew ignored it and quarelled with Henning instead.  I  suggest we 
>> go with Marc's formulation with a slight tweak:
> 
> 
> I did not see Marc's message, and still do not see it in my local  
> copy or the IETF archives (I'm not doubting it was sent, I'm just  
> curious why I missed it).
> 
> BTW, I was not the only one with objections to R5.  Ted proposed an 
> alternative as well.
> 
>> "R5: The mapping protocol should allow for alternative redundant 
>> sources of mapping information, possibly of different degrees of 
>> currency.
>>
>> "Motivation: This provides the possibility of having available 
>> alternative sources of mapping information when the normal source  is

>> unavailable or unreachable, without specifying the means by  which 
>> the alternative source is created or updated."
>>
>> I think this proposition has concrete implications for protocol 
>> design, hence should be stated.
> 
> 
> Well, I like this much better than the current version.  Perhaps a 
> slight tweak:
> 
> R5: The mapping protocol should not inhibit the deployment of 
> alternative redundant sources of mapping information, possibly of 
> different degrees of currency."
> 
> -andy
> 
> 

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

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 19 Sep 2005 16:07:46 -0400

This sounds totally like a deployment requirement, I'm afraid.  I can't 
see the protocol implications.

> Does this capture what we want to say about this topic?
...