Subject: [Ecrit] draft-ietf-ecrit-requirements-13 as a result of AD comments

From: "Roger Marshall" <[email-masked]>
Date: Fri, 2 Mar 2007 18:23:01 -0800

I've updated the requirements draft, which has been submitted, and will
get posted as draft-ietf-ecrit-requirements-13 soon.  

RE: Change log to document changes from:
draft-ietf-ecrit-requirements-12 to upcoming version -13.
Date: 3/02/07
By: R. Marshall

C1. Delete following requirement Ma18, since it is not clear how it is
different than Ma15.

Ma18.  Alternate mapping sources: The mapping protocol MUST implement a
mechanism that allows for the retrieval of mapping information from
different sources.

Motivation: This provides the possibility of having available
alternative sources of mapping information when the normal source  is
unavailable or unreachable.

C2. Renumber Ma19 to Ma18 per above.

C3. Change last paragraph to section 1, based on Jon's comment:
I expected the last paragraph in Section 1 to have an additional 
>> sentence saying something to the effect that the latter use 
>> (displaying location information at the PSAP) is orthogonal to the 
>> mapping protocol problem and the scope of this document.

Change from:

Location is required for two separate purposes, first, to support the
routing of the emergency call to the appropriate PSAP and second, to
display the caller's location to the call taker to help in dispatching
emergency assistance to the appropriate location.

Change to: (appended paragraph)

Location is required for two separate purposes, first, to support the
routing of the emergency call to the appropriate PSAP and second, to
display the caller's location to the call taker to help in dispatching
emergency assistance to the appropriate location.

This latter use, the display of location information to the PSAP, is
orthogonal to the mapping protocol, and is outside the scope of this
document.

C4. Change term "Internet Attachment Provider", based on comment below:

>> 3.2 - The term "Internet Attachment Provider" is not a common one, 
>> and doesn't seem to be distinguished from the more common concept of 
>> an access network. I would suggest that "access network" at least be 
>> provided as a synonym in the definition.
>
> My suggestion would be to switch to "Internet Access Provider", as 
> that seems closer to common usage. Plus, 'attachment' is probably not 
> a good fit for, say, 'unattached' network connections, such as
wireless..

Change from: "Internet Attachment Provider" to: "Internet Access
Provider" 
(throughout, including diagram).

C5. Change definition of ESRP from a B2BUA, to something more general,
per the folowing AD review comment.

>> 3.4 - I'm not sure what the need is to suggest that the ESRP function

>> might be performed by a B2BUA. At a high level, I suppose I see the 
>> mapping client function as one that could be performed by a number of

>> entities, including entities that instantiate the SIP proxy role and 
>> the SIP user agent client role. I think language to that effect would

>> be preferable to suggesting that there is some motivation for pairing

>> the mapping client function with a B2BUA.

Change from:

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

Change to:

   Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call
      routing support entity that invokes the location-to-PSAP URI
      mapping function, to return an appropriate PSAP URI, or the
      URI for another ESRP.  Client mapping requests could also be 
      performed by a number of entities, including entities that 
      instantiate the SIP proxy role and the SIP user agent client role.

C6. Fix broken sentence, (per comment below):

>> (Emergency) service URL: The service URL is a protocol-specific 
>> (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the address

>> of the PSAP or other emergency service.
>>
>> after the im: citation, you probably want the words: "identifier 
>> which"
>>
Yes, "identifier which" must be added.

Change from:

   (Emergency) service URL: The service URL is a protocol-specific
      (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the
      address of the PSAP or other emergency service.  It depends on the
      specific signaling or data transport protocol used to reach the
      emergency service.

Change to:

   (Emergency) service URL: The service URL is a protocol-specific
      (e.g., SIP) or protocol-agnostic (e.g., im: [5]) identifier which
contains the
      address of the PSAP or other emergency service.  It depends on the
      specific signaling or data transport protocol used to reach the
      emergency service.

C7. Change Lo5 Heading (per comment below):

>> In Section 6, why is Lo5 called "Validation resolution"? The 
>> description of the requirement doesn't seem to relate to validation 
>> or resolution, as far as I can tell. "Additional Information" or 
>> something might be a better name for this requirement.
>
> I agree that the heading is not helpful. I'd suggest calling it
>
> Information about location data used for mapping
>
>
I agree that changing the heading would help to make it clearer.

Change Lo5 heading from: "Validation resolution" 

Change Lo5 heading to: "Information about location data used for
mapping"

C8. 

>> In Section 8, Ma11 uses the seemingly innocuous name "URI properties"
>> to provide requirements that seem to contradict Ma8. If the mapping 
>> protocol is going to return multiple PSAP URIs as described in Ma11, 
>> there should be a story stronger than "local policy" to meet the 
>> requirement of Ma8. You might want to find a better name for Ma11 
>> than "URI properties", too.

[RM comment - Whereas Ma8 is a SHOULD, i.e., that it is optimal for only
one URI be returned, yet it allows for cases where more than one may be
returned, Ma11 is a MUST, i.e., must be able to return extra info to
help pick one URI over the other - in the case where there are multiple
URIs returned.  I see no contradiction between the two reqs.]

No change made to either Ma8 or Ma11.

C9. Change to Ma15 Heading, change from, "Resilience to failure" to,
"Resilience to mapping server failure" (per the comments below).

[above comment con't]
>>
>> Also in 8, how is Ma15 different from Ma18?
>
> I'm not sure I'm interpreting your question correctly, but Ma15 talks 
> about reliability of the mapping protocol, while Ma8 talks about 
> returning mappings to achieve reliability. To make this clearer, the 
> title in Ma15 should be changed to
>
> Resilience to mapping server failure
>
I also believe that the problem would be fixed by changing the heading
of Ma15 to "Resilience to mapping server failure".

C10. Delete requirement Ma9 (per Henning's/Hannes' comments below):

> By the way, we've decided to not do Ma9, based on additional 
> discussion, so I'd suggest dropping it. Not that anybody is going to 
> do a point-by-point comparison of LoST to the requirements document...
>
I would also suggest to delete Ma9.

Requirement Ma9 deleted.
Requirements Ma10-Ma18 now renamed to Ma9-Ma17.

/end.

Roger Marshall  

>-----Original Message-----
>From: Hannes Tschofenig [mailto:[email-masked]]
>Sent: Friday, March 02, 2007 6:12 AM
>To: Peterson, Jon
>Cc: Henning Schulzrinne; [email-masked]; Roger Marshall; 
>Marc Linsner
>Subject: Re: AD review of draft-ietf-ecrit-requirements-12.txt
>
>Hi Jon,
>
>Ma15 vs. Ma18: Let's delete Ma18. I cannot figure out what the 
>difference is to Ma15.
>
>Ciao
>Hannes
>
>
>Peterson, Jon wrote:
>>>>> Also in 8, how is Ma15 different from Ma18?
>>>>>         
>>>> I'm not sure I'm interpreting your question correctly, but
>>>>       
>>> Ma15 talks
>>>     
>>>> about reliability of the mapping protocol, while Ma8 talks about 
>>>> returning mappings to achieve reliability. To make this
>>>>       
>>> clearer, the
>>>     
>>>> title in Ma15 should be changed to
>>>>
>>>> Resilience to mapping server failure
>>>>
>>>>       
>>> I also believe that the problem would be fixed by changing the 
>>> heading of Ma15 to "Resilience to mapping server failure".
>>>
>>> Ma8 is fine as it is and fits perfectly what we did in the protocol 
>>> design.
>>>     
>>
>> For the record, I was asking how Ma15 is different from
>-Ma18-, not -Ma8-.
>>
>> - J
>>   
>
>

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Mar 2007 17:14:35 +0200

Let me also add that the changes were made based on a review by Jon.
Thanks Jon for the review comments and for the quick interaction to 
resolve them.

Ciao
Hannes