Subject: [Ecrit] Review: draft-ietf-ecrit-framework-01.txt

From: Shida Schubert <[email-masked]>
Date: Wed, 09 May 2007 00:26:26 -0700

Draft: draft-ietf-ecrit-framework-01
Reviewer: Shida Schubert
Review Date: 2007.05.02

Summary:
----------------------------------------
 - Overall I think it's a well written draft giving a 
   really good overview of how everything interacts.
 
 - The draft needs some overhaul reflecting all the recent 
   discussions in ECRIT, GEOPRIV and SIP WG regarding 
   location hiding, emergency call verification, L7 LCP etc. 

 - The terminology needs to be aligned with the current version 
   of requirement/LoST draft.

Technical Comments:
----------------------------------------
 T1: Chapter 3, 1st paragraph, 1st sentence.
   - Although we haven't come to a conclusion on how emergency 
    call is distinguished, I believe the currently many see it 
    as either by a emergency dialstring or by service URN. 
   - The current text seems to allude that dialstring is necessary 
    to place the (Emergency) service URN.    

 T2: Chapter 4, 3rd paragraph, 3rd sentence.
   - I don't think the following text is true. 
   "It should be noted that the endpoint would not normally supply 
   location unless it understood the call to be an emergency call." 
   > I see this to be somewhat misleading. It's true in case of 
   an emergency if UA supports location, it should without a doubt 
   include location information but the statement above is definitely 
   not correct. If the text is merely a note, it may be good to simply 
   remove the text.

 T3. Chapter 5.8, 1st paragraph, 1st sentence. 
  - Although not a normative text, "Location must be validated" seems a bit 
    too strong. I don't have a strong feeling for this but I prefer something 
    like a should rather than a must.. 

Clarification Needed:
----------------------------------------
 C1: Chapter 2, last 2 paragraphs. 
  - It's unsure what "this document", "this draft" is pointing at. 
    From the context it seems to be pointing at the phone-bcp but 
    it's unclear. 

 C2: Chapter2, last 2 paragraphs.
  - If these paragraphs are indeed about phone-bcp then the last 
    sentence is incorrect. As far as I understand phone-bcp will 
    have recommended behavior of LoST, proxy(outbound and others) 
    and UAs.  

 C3: Chapter 3, 3rd paragraph, 3rd sentence.
  - The reason why registration is necessary is not mentioned here. 
    If it's for call-back purpose I think it should be mentioned  
    as well. What about non-authorized device that can't REGISTER? 

 C4: Chapter 5.3, 3rd paragraph, 2nd sentence. 
  - It's unclear what policy you mean by "To facilitate such 
    policy decision".

 C5: Chapter 5.3, 3rd paragraph, 3rd sentence. 
  - What do you mean by the generator of the location information?
    Is generator same as whatever goes into the <provided-by> in 
    PIDF-LO?

Editorial Comments:
----------------------------------------	
 E1: Chapter 3, 1st paragraph, 1st sentence.
   - Although we haven't come to a conclusion on how emergency 
    call is distinguished, I believe the currently many see it 
    as either by a emergency dialstring or by service URN. 
   - The current text seems to allude that dialstring is necessary 
    to place the (Emergency) service URN.   

 E2: Chapter 3, 2nd paragraph, 3rd bullet, last sentence. 
   - Term LoST dip is used although one can assume what it means, 
     it's not the term used in LoST document thus should probably 
     use the proper term used in LoST document. (Same term is used 
     in section 6, 2nd last paragraph)

 E3: Chapter 3, 2nd paragraph, 4th bullet, 1st sentence.
   - Service URN is not mentioned as the parameter used to resolve 
     PSAP URIs. 

   OLD: LoST Server - Processes the LoST request for Location to PSAP-URI
      Mapping function, either for an initial request from a UA, or an
      in-call routing by the Proxy server in the originating network, or
      possibly by an ESRP.     

   NEW: LoST Server - Processes the LoST request for Location + Service URN
      to PSAP-URI Mapping function, either for an initial request from a UA, 
      or an in-call routing by the Proxy server in the originating network, 
      or possibly by an ESRP. 

 E4: Chapter 3, 3rd paragraph, 2nd sentence.
   - Acronym LCP is used without any introduction to it. The following text 
     change should be made where location configuration protocol is mentioned. 

   OLD: Generally, Alice's UA either has location configured manually, has an
        integral location measurement mechanism, or it runs a location
        configuration protocol to obtain location from the access (broadband)
        network.

   NEW: Generally, Alice's UA either has location configured manually, has an
        integral location measurement mechanism, or it runs a location
        configuration protocol (LCP) to obtain location from the access (broadband)
        network.

 E5: Chapter 3, 3rd paragraph, 4th sentence.
  - The reason to obtain PSAP URI prior to making an emergency call 
    is to have something to use in case of LoST failure at emergency 
    time and also for testing.

    OLD: Next, her UA will perform an initial LoST Location-to-PSAP SIP(S)-URI 
         query to learn a URI, for use if the Lost Query fails during an 
         emergency call.
    NEW: Next, her UA will perform an initial LoST Location-to-PSAP SIP(S)-URI 
         query to learn a URI, for use if the Lost Query fails during an 
         emergency call or to use it to test emergency call.

 E6: Chapter 5.3, 4th paragraph, last sentence.
  - The reference to location conveyance is currently to that of LoST. Needs to be 
    fixed.

 E7: Chapter 5.5, 3rd paragraph, last sentence.
  - The reference is made to LoST which should be changed to Phone-BCP. 

 E8: Chapter 5.8. 
  - Although not a normative text, "Location must be validated" seems a bit 
    too strong. 
 
 E9: Chapter 10, 2nd paragraph, 1st sentence. 
  - redundant "of".

 I hope it helps.

Thanks & Regards

--
Shida Sven Schubert           
[email-masked]	PHONE: (604) 762-5606 

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