Subject: [Ecrit] Requirements Draft close to completion

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sat, 4 Feb 2006 19:54:44 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sat, 4 Feb 2006 20:01:12 +0100

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,activity,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: [email-masked]'
> 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!
> 
> 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. 
> 
> - Roger will add information to each requirement to indicate 
> whether the RFC 2119 language refers to 
>   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
>

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 14 Feb 2006 13:40:26 +0100

Folks,

first I want to thank all participants of the interim meeting and
especially Roger for the excellent work done finalizing the requirements
draft.

I have not yet cross-checked the draft with the meeting minutes
completely, but on the first complete read I have not found any
open issues not addressed.

I am also the opinion that the draft is after the below announced
re-submission ready for WGLC.

Cheers

Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Tschofenig, Hannes
> Sent: Saturday, February 04, 2006 7:55 PM
> To: [email-masked]
> Subject: [Ecrit] Requirements Draft close to completion
> 
> Hi all,
>

---

From: "Abbott, Nadine B" <[email-masked]>
Date: Wed, 15 Feb 2006 09:08:46 -0500

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.

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

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

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

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.>>
     
Regards,
Nadine Abbott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes
Sent: Saturday, February 04, 2006 2:01 PM
To: [email-masked]
Subject: [Ecrit] AW: Requirements Draft close to completion

Hi all, 

ciao
hannes
> 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
> 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.
> 
> - Roger will add information to each requirement to indicate whether 
> the RFC 2119 language refers to
> - We would then like to start a WGLC on the 20th February running for 
> 2 weeks.
> 
> constructive feedback (e.g., text suggestions instead of just stating 
> 'i don't like it').
> 
> Ciao
> Hannes & Marc
>

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 16 Feb 2006 16:43:56 -0800

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

-roger. 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Abbott, Nadine B
>Sent: Wednesday, February 15, 2006 6:09 AM
>To: [email-masked]
>Subject: RE: [Ecrit] AW: Requirements Draft close to completion
>
>Hannes, Roger, all,
>
>After reviewing my notes, the meeting minutes and logs, I'd 
>like to suggest a few small text edits in the requirements documents.
>

Suggested change accepted for next version.

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

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

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

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

>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