Subject: [Gen-art] Gen-ART review of draft-ietf-ecrit-requirements-13.txt

From: Suresh Krishnan <[email-masked]>
Date: Thu, 21 Jun 2007 19:18:09 -0400

I am the assigned Gen-ART reviewer for
draft-ietf-ecrit-requirements-13.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

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

Cheers
Suresh

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Jun 2007 10:34:43 -0400

I received this review after the IESG telechat.

At 07:18 PM 6/21/2007, Suresh Krishnan wrote:
>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
>
>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
>
>Not sure who this requirement is on. Perhaps reword the requirements 
>so that it becomes clear who needs to satisfy the requirements.
>
>
>* Requirement Id6
>