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

From: "Bob Natale" <[email-masked]>
Date: Thu, 23 Mar 2006 11:49:11 -0500

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.

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.

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)?

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?

C5: Sec. 5, Identifying the Caller's Location, p. 14:
NIT: First sentence: "direct" s/b "directly".

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.

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?

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

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.

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

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.
- - - - -
-----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-requirements-06.txt

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