Subject: [Ecrit] RE: Review comments -- draft-ietf-ecrit-requirements-06.txt

From: "Roger Marshall" <[email-masked]>
Date: Wed, 19 Apr 2006 14:16:09 -0700

Bob:
Thanks for your comments on the draft. 

Most of your comments have been taken into account per my responses,
(see inline).
However, due to a mistake on my part, not all which were noted will make
it into the very next version, but rather the follow-on version.  My
apologies for missing those.

Thanks.

Roger Marshall.

>-----Original Message-----
>From: Bob Natale [mailto:[email-masked]] 
>Sent: Thursday, March 23, 2006 8:49 AM
>To: [email-masked]; Roger Marshall
>Cc: [email-masked]
>Subject: Review comments -- draft-ietf-ecrit-requirements-06.txt 
>
>Hi,
>
>FWIW, my review comments below.
>
>This is my first review of an ECRIT document and a view of my 
>comments are motivated by associated interest in the SPEERMINT 
>work, so feel free to calibrate accordingly.  (Also, written 
>on a plane under less than ideal conditions. :)
>
>Overall, I think it is an excellent document (informative, 
>well-organized), and a very good model to follow for similar 
>documents (esp. the "Motivation"
>notes).
>
>Cheers,
>BobN
>- - - -
>C1: Sec 1., Introduction, p. 3:
>   "This document only focuses on end-to-end IP-based calls, 
>i.e., where
>   the emergency call originates from an IP end system and terminates
>   into an IP-capable PSAP, conveyed entirely over an IP network.
>   ...
>   Ideally, the mapping protocol would yield a URI from a preferred set
>   of URIs (e.g., SIP:URI, SIPS:URI) which would allow an 
>emergency call
>   to be completed using IP end-to-end.  Despite this goal, some PSAPs
>   may not immediately have IP based connectivity, and therefore it is
>   imperative that the URI scheme not be fixed, in order to ensure
>   support for a less preferred set of URIs, such as a TEL URI 
>which may
>   be used to complete a call via the PSTN."
>
>The rationale behind the "Despite..." in the second quoted paragraph
>*seems*
>to be inconsistent with the document focus stated in the first 
>quoted paragraph.  I understand that "focus" does not mean 
>exclusivity; but I think the gap between focus on "all IP" and 
>a (realistic) recognition of the need to support PSTN 
>connectivity is too wide to accept without explicit 
>explanation in the document. I am stressing this point a bit 
>more than I would otherwise, because I think the same 
>(realistic) recognition might be needed in other current RAI 
>Area efforts.

If you have a suggested rewrite of the text, I'd be happy to receive it.

>
>C2: Sec. 2, Terminology, p. 6:
>NIT: The defection of ESRP needs a closing paren on the last 
>sentence, or removal of the opening paren.
>
Changes made.

>C3: Sec. 2, Terminology, p. 8:
>The definition for VSP again brings in PSTN termination (realistic).
>Is this also valid for SPEERMINT consideration (perhaps 
>especially in the Access SP entities)?
>
I'm not sure what changes should be made to the text here.

>C4: Sec. 4, High-Level Requirements, p. 13:
>The phrase "in any unusual or unreasonable way" is not 
>sufficiently empirical -- how can compliance be verified?
>
I'll leave this one to the list for input.

>C5: Sec. 5, Identifying the Caller's Location, p. 14:
>NIT: First sentence: "direct" s/b "directly".
>
Changes made to follow-on version.

>C6: Sec. 5, Identifying the Caller's Location, p. 14:
>Suggest that a better moniker for Lo2 (currently "Location 
>provided") might be "Location object/info preservation", or 
>something like that.
>
Changes made to follow-on version.

>C7: Sec. 6, Emergency Identifiers, p. 15:
>Concerning the assertion in Id3 that "This marking mechanism 
>must be different than QoS marking"...why?  What, precisely, 
>is meant by "QoS marking".  Why isn't "Emergency Call" a valid 
>QoS "marking"?  Any tie-in with MLPP stuff?
>
I'll leave this one to be brought to the list.

>C8: Sec. 6, Emergency Identifiers, p. 15:
>Suggest that the "and" in Id5 should break it into two 
>separate requirements.  (General requirements practice of mine 
>-- might be excessive on my part, but if accepted, might also 
>apply to other cases in this draft).
>
Paragraph has been reworded.

>C9: Sec. 6, Emergency Identifiers, p. 16:
>Concerning this text in Id11 -- "MUST support (i.e., 
>implement, though not necessarily use)":
>(a) I don't really understand what is meant: My supposition is 
>that there must be at least one use case to justify 
>implementation.  What is the intended scope of "not necessarily use"?
>(b) [This point was made by another commenter, on an earlier 
>version of the draft, I believe.] Regardless of (a), the 
>various forms in which that general text (i.e., the 
>parenthetical explanatory text following "MUST support") is 
>used throughout the document is very confusing.
>
Changed throughout.

>C10: Sec. 7, Mapping Protocol, p. 18:
>the single sentence that constitutes the entire first 
>paragraph is hard to follow -- I think there is a wording 
>problem centered on the word "one", as well as the need for an 
>overall re-write...?
>
Text has been reworded.

>C11: Sec. 7, Mapping Protocol, p. 19:
>I think that the inclusion of "Motivation" statements for each 
>requirement is a very good idea (and I propose to use it in 
>the SPEERMINT Requirements BCP).  I read that you deliberately 
>removed that part from at least one of the requirements in 
>this draft (e.g., Ma4).  I would like to ask that "Motivation" 
>statements be provided for all Requirements statements.  It's 
>very helpful info.

Motivation sections now accompany each stated requirement.

>- - - - -
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, March 08, 2006 3:50 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-06.txt 
>
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>This draft is a work item of the Emergency Context Resolution 
>with Internet Technologies Working Group of the IETF.
>
>	Title		: Requirements for Emergency Context  Resolution
>with Internet Technologies
>	Author(s)	: H. Schulzrinne, R. Marshall
>	Filename	: draft-ietf-ecrit-requirements-06.txt
>	Pages		: 29
>	Date		: 2006-3-8
>	
>This document enumerates requirements for the context resolution of
>   emergency calls placed by the public using voice-over-IP (VoIP) and
>   general Internet multimedia systems, where Internet protocols are
>   used end-to-end.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requiremen
>ts-06.txt
>

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