RE: [Ecrit] AW: Requirements Draft close to completion

["Roger Marshall" <[e-mail]>]

Nadine:
Thanks very much for your feedback.  See my responses inline.

-roger. 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Abbott, Nadine B
>Sent: Wednesday, February 15, 2006 6:09 AM
>To: [e-mail]
>Subject: RE: [Ecrit] AW: Requirements Draft close to completion
>
>Hannes, Roger, all,
>
>Thanks to Roger for the quick turn-around and heroic efforts 
>to capture lively discussion in text.
>After reviewing my notes, the meeting minutes and logs, I'd 
>like to suggest a few small text edits in the requirements documents.
>
>1) Thanks for adding a definition for PSAP URI.  It would help 
>to add the example of ESRP, I think. 
>The change text is <<bracketed>> to say:
>    PSAP URI: PSAP URI is a general term, used to refer to the 
>output of
>              the mapping protocol, and represents either the 
>actual PSAP IP
>              address, or <<the IP address of some other 
>intermediary, e.g., 
>              an ESRP,>> which points to the actual PSAP.

Suggested change accepted for next version.


>
>2) Need to add a definition for the acronym LCMS or spell out 
>(used in requirement Ma24X).

Added definition for LCMS, and defined as follows, (based on language found in draft-polk-newton-ecrit-arch-considerations-01.txt):

"Location Context Mapping System (LCMS): A system 
defined as a set of mechanisms and services working together to 
perform a mapping, (or, direct association), between a location and a 
PSAP uri designated as responsibleto to serve that location."


>
>3) Minor edits:
>   Ma7: Multiple PSAP <<URIs>>   (no apostrophe needed)
>   Ma9: replace "urii" with "uri"

Ma7: done
Ma9X: done

>
>4) We added two new requirements to further clarify the 
>requirements on the protocol in responding to location 
>validation requests: Lo1X and Lo1XX.  I think I understand 
>them, but I am not sure that someone not involved in the 
>discussion would understand them the same way. In the 
>discussion (see posted meeting notes) we said: "Do we agree 
>that we need a result code, in addition to a URI? Partial 
>validation may be the common case (public verifiers won't know 
>suite numbers/room numbers, for example)... The protocol MUST 
>have the mechanism (whether it gets used or not is up to the 
>administration)." I think it would clarify requirement Lo1X to 
>add a motivation with wording like the following in <<brackets>>. 
>   
>   Lo1X. Validation Resolution: The mapping protocol MUST support the
>      return of additional information which can be used to determine
>      the precision or resolution of the data elements used to 
>determine
>      a PSAP URI, for example.
>    
>      <<Motivation: The mapping server may not use all the 
>data elements 
>                  in the location in determining a match, or 
>may be able 
>                  to find a match for all but specific tags.  
>                  The specifics of the information used may vary among 
>                  emergency jurisdictions. Precision or 
>resolution in the context 
>                  of this requirement might mean, for example, 
>explicit identification 
>                  of the data elements that were used 
>successfully in the mapping.>> 

Added Motivation section to Lo1X, based on (though reworded) text provided above:

"Motivation: The mapping server may not use all the data elements in 
the provided location information to determine a match, or may be able to 
find a match based on all of the information execept for some specific 
data elements.  The uniqueness of this information set may be used to 
differentiate among emergency jurisdictions.  Precision or resolution in 
the context of this requirement might mean, for example, explicit 
identification of the data elements that were used successfully in the 
mapping."

Please let me know if this does NOT convey what you wanted to say.


>
>5) There was also another idea that I think it would be 
>valuable to capture--that it is useful to be able to provide 
>in the response a URI that the client can then use to further 
>resolve problems.  (See posted meeting notes: "Does the ECRIT 
>protocol need to provide a way to fix data that's wrong in the 
>database? No, but is it helpful to provide a URL for a 
>mechanism that would help in fixing the data? NENA did this - 
>it's actually helpful. We can't tell whether the user is wrong 
>or the database is wrong.") I think this is a requirement on 
>the protocol and is more than just an indication that 
>something is wrong.  Therefore, I suggest that we add text 
>like the following in <<brackets>> to Lo1XX, plus maybe a 
>Motivation with wording like that below in <<brackets>>. 
>
>   Lo1XX.  Indication of non-existent location: The protocol MUST
>      support a mechanism to indicate that a location or a part of a
>      location is known to not exist, even if a valid location-to-PSAP
>      uri mapping can be provided. <<This mechanism shall 
>support inclusion 
>      of a means to identify a separate mechanism to resolve 
>the discrepancy.>>
>
>      <<Motivation:  The emergency jurisdictional authority 
>may provide a means 
>                     to resolve addressing problems,  e.g., a 
>URI for a web service 
>                     that can be used to report problems with 
>an address. 
>                     The response should allow this service to 
>be identified.>>

I've rewritten the requirement Lo1XX some, taking into consideration the suggested text as well as provided a parenthetical for purposes of clarifying per RFC 2119.  A Motivation text block has also been added (though reworded some from the original suggested text).

"Lo1XX.  Indication of non-existent location: The 
protocol MUST support (i.e. must implement in the protocol, though not 
necessarily use), a mechanism to indicate that a location or a 
part of a location is known to not exist, even if a valid location-to-PSAP 
uri mapping can be provided.  This mechanism includes a means to 
identify a separate mechanism that could be used to resolve the 
discrepancy."

"Motivation:  The emergency authority for a given jurisdiction may 
provide a means to resolve addressing problems,  e.g., a URI for a 
web service that can be used to report problems with an address.  
The mapping response would allow this service to be identified."

Please let me know if this does NOT coincide with what you were trying to say.

Roger Marshall


>     
>Regards,
>Nadine Abbott
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Tschofenig, Hannes
>Sent: Saturday, February 04, 2006 2:01 PM
>To: [e-mail]
>Subject: [Ecrit] AW: Requirements Draft close to completion
>
>Hi all, 
>
>The issue tracker is currently empty since Roger closed all of them. 
>If you want to retrieve the full list of issues (including all 
>closed issues) please use the following link:
>http://www.ietf-ecrit.org:8080/ecrit-req/issue?:columns=id,acti
vity,title,creator,assignedto,status&:sort=id&:group=status&:pagesize=50&:startwith=0
>
>ciao
>hannes
>> -----Ursprüngliche Nachricht-----
>> Von: Tschofenig, Hannes
>> Gesendet: Samstag, 4. Februar 2006 00:38
>> An: '[e-mail]'
>> Betreff: Requirements Draft close to completion
>> 
>> Hi all,
>> 
>> the first day of the interim meeting was spend to walk through the 
>> open issues of draft-ietf-ecrit-requirements-02.txt. We were able to 
>> close ALL open issues. Thanks to all the participants.
>> 
>> Roger has already incorporated the suggested changes into a new 
>> version and he submitted the document already. Please find it at
>> http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-
>> 03.txt (before it appears in the IETF archive).
>> Thank you Roger!
>> 
>> To make sure that we have indeed addressed all open issues listed at 
>> http://www.ietf-ecrit.org:8080/ecrit-req
>> correctly we would like to ask everyone to review the document again 
>> and to ask those people who haven't had the chance to attend the 
>> interim meeting to carefully inspect whether their open issue was 
>> adequately addressed.
>> 
>> The next steps for this document are as follows:
>> 
>> - Roger will add information to each requirement to indicate whether 
>> the RFC 2119 language refers to
>>   (a) a requirement for an implementation or to
>>   (b) a requirement for usage
>>   He will then resubmit the document. Targeted resubmission
>> date: next week
>> 
>> - We would then like to start a WGLC on the 20th February running for
>> 2 weeks.
>> 
>> Since these goals are quite ambitious we would like to ask for your 
>> help. Please review the document as early as possible AND make 
>> constructive feedback (e.g., text suggestions instead of 
>just stating 
>> 'i don't like it').
>> 
>> Ciao
>> Hannes & Marc
>> 
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ecrit
>

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