[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ecrit] Review: draft-ietf-ecrit-framework-01.txt
I am (finally working on framework-02 and am working through your comments. See inline
> -----Original Message-----
> From: Shida Schubert [mailto:shida at ntt-at.com]
> Sent: Wednesday, May 09, 2007 3:26 AM
> To: ECRIT
> Subject: [Ecrit] Review: draft-ietf-ecrit-framework-01.txt
>
> 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.
The sentence currently reads:
We distinguish (Section 4 (Identifying an Emergency Call)) an emergency call from any other call by a unique Service URN[IâD.ietfâecritâserviceâurn] (Schulzrinne, H., âA Uniform Resource Name (URN) for Services,â August 2006.), which is placed in the initial call set-up signaling when a home or visited emergancy dialstring is detected.
What other way, other than recognizing the dialstring would there be?
"Emergency" buttons are not a good idea, because they cause too many false calls. The text at this point doesn't say if the endpoint or server detects the dialstring. The dialstring isn't an emergency call until itâs detected as such by the endpoint or proxy, at which time it gets the service URN. Perhaps you could elaborate on your concern and suggest some changes.
>
> 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.
I deleted it because the section is not about location.
>
> 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..
I added "In some jurisdictions" and "and is always recommended'
>
> 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.
I reworded parts of the text. Take a look and see if I have fixed what you were confused about
>
> 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.
The paragraphs were supposed to refer to the framework doc. Hopefully, the edits make it more clear, although it doesn't matter if you read them as applying to -phonebcp.
>
> 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?
I added the reason. I added text in location and call back discussing uninitialized devices.
>
> C4: Chapter 5.3, 3rd paragraph, 2nd sentence.
> - It's unclear what policy you mean by "To facilitate such
> policy decision".
Fixed
>
> 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?
Fixed. It is "provided-by"
>
>
> 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.
See above
>
> 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)
Fixed
>
> 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.
Fixed
>
> 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.
Fixed
>
> 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.
Fixed
>
> E6: Chapter 5.3, 4th paragraph, last sentence.
> - The reference to location conveyance is currently to that of LoST.
> Needs to be
> fixed.
Fixed
>
> E7: Chapter 5.5, 3rd paragraph, last sentence.
> - The reference is made to LoST which should be changed to Phone-BCP.
Fixed
>
> E8: Chapter 5.8.
> - Although not a normative text, "Location must be validated" seems a
> bit
> too strong.
Addressed, as above
>
> E9: Chapter 10, 2nd paragraph, 1st sentence.
> - redundant "of".
Fixed
>
>
>
> I hope it helps.
Yes, it did, thank you
Brian
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit