Document: draft-ietf-ecrit-requirements-13.txt
Reviewer: Suresh Krishnan [suresh.krishnan@ericsson.com]
Review Date: 6/21/2007 
IESG Telechat Date: 6/21/2007 

Summary: This draft is ready for publication, but I have some suggestions.

Comments: Overall the draft is well written and it is a really good idea 
to include the motivation along with the requirements. Since this is my 
first brush with this technology, please excuse me if some of the 
comments are too basic.


Semi-substantial
================

* Requirement Lo4

If the location validation failed, it would be a good idea to let the 
client know, Perhaps add something like this

"If location validation fails, the mapping protocol MUST convey the 
error to the client"


* Requirement Re6

Isn't this a requirement on the mapping server rather than the protocol?


* Requirement Lo7

Since I do not see how invalid locations will be mapped to a PSAP, why 
is this required?


Minor
=====

* Requirement Re7

I am not sure what "common data structures and formats" means. Does it 
mean commonly used data structures and formats?


* Requirement Lo8

This perhaps needs to be a requirement on mapping clients, servers and 
protocols and not just protocols


* Requirement Id1

Why does the mapping protocol need to distinguish between different 
emergency services? Isn't it the mapping service that needs to be aware.


* Requirements Id5, Id7, Id9

Not sure who this requirement is on. Perhaps reword the requirements so 
that it becomes clear who needs to satisfy the requirements.


* Requirement Id6

I am not sure about the scope of this requirement. What signaling 
protocols are covered by this requirement? Is it ALL signaling protocols?


Editorial
=========

* There are a few occurences of non-normative language where normative
   language may be used in order to conform to the overall style of the
   document.

   - Perhaps use Normative MUST?

    Id8.  Return fallback service identifier:  The mapping protocol must
       be able to report back the actual service mapped if the mapping
       protocol substitutes another service for the one requested.

   - Perhaps use Normative MAY?

    Lo8. 3D sensitive mapping:  The mapping protocol MUST implement
       support for both 2D and 3D location information, and may accept
       either a 2D or 3D mapping request as input.

* Newer draft versions are available for

   draft-ietf-ecrit-security-threats &
   draft-ietf-ecrit-service-urn