Subject: [Ecrit] [Fwd: AD review of draft-ietf-ecrit-requirements-12.txt]

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Mar 2007 13:24:04 +0100

Hi all,

I am the PROTO shepherd for draft-ietf-ecrit-service-urn. You can find 
Jon's review in the attachment. Henning published a draft update. Here 
is the diff version:
http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/draft-ietf-ecrit-requirements-13-from-12.diff.html

Here is the list of updates:
* Update to the introduction
* Terminology: Changed "Internet Attachment Provider (IAP)" to "Internet 
Access Provider (IAP)"; Updated "Emergency Service Routing Proxy (ESRP)" 
term
* Editorial change to Lo5
* Deleted requirement Ma9 regarding "URI alternate contact"
* Clarified Ma15
* Deleted requirement Ma18 regarding "Alternate mapping sources"
* Boilerplate update

Scanning through the diff I noticed two nits:
* The intended status of the document is not "Standards Track"
* I-D.hardie-ecrit-lost reference needs to be replaced with 
I-D.ietf-ecrit-lost

Ciao
Hannes

-------- Original Message --------
Subject: 	AD review of draft-ietf-ecrit-requirements-12.txt
Date: 	Fri, 2 Mar 2007 06:30:00 -0500
From: 	Peterson, Jon <[email-masked]>
To: 	<[email-masked]>, <[email-masked]>
CC: 	Hannes Tschofenig <[email-masked]>, Marc Linsner 
<[email-masked]>

Document is in fine shape. You may need a pass to meet current I-D nits constraints introduced since it was last issued.

I expected the last paragraph in Section 1 to have an additional sentence saying something to the effect that the latter use (displaying location information at the PSAP) is orthogonal to the mapping protocol problem and the scope of this document.

3.2 - The term "Internet Attachment Provider" is not a common one, and doesn't seem to be distinguished from the more common concept of an access network. I would suggest that "access network" at least be provided as a synonym in the definition.

3.4 - I'm not sure what the need is to suggest that the ESRP function might be performed by a B2BUA. At a high level, I suppose I see the mapping client function as one that could be performed by a number of entities, including entities that instantiate the SIP proxy role and the SIP user agent client role. I think language to that effect would be preferable to suggesting that there is some motivation for pairing the mapping client function with a B2BUA.

3.6 - This sentence is broken:    

	(Emergency) service URL: The service URL is a protocol-specific
      (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the
      address of the PSAP or other emergency service. 

after the im: citation, you probably want the words: "identifier which"

In Section 6, why is Lo5 called "Validation resolution"? The description of the requirement doesn't seem to relate to validation or resolution, as far as I can tell. "Additional Information" or something might be a better name for this requirement.

In Section 8, Ma11 uses the seemingly innocuous name "URI properties" to provide requirements that seem to contradict Ma8. If the mapping protocol is going to return multiple PSAP URIs as described in Ma11, there should be a story stronger than "local policy" to meet the requirement of Ma8. You might want to find a better name for Ma11 than "URI properties", too.

Also in 8, how is Ma15 different from Ma18?

- J

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

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 21 Mar 2007 06:13:17 -0700

Hannes:
Clarification: I think what we're talking about is the
draft-ietf-ecrit-requirements, (rather than service-urn).  As such, the

>* The intended status of the document is not "Standards Track"

Changed this to "info"

>* I-D.hardie-ecrit-lost reference needs to be replaced with 

Done.

Anything else?

-roger marshall.

>-----Original Message-----
>From: Hannes Tschofenig [mailto:[email-masked]] 
>Sent: Wednesday, March 21, 2007 5:24 AM
>To: ECRIT
>Subject: [Ecrit] [Fwd: AD review of 
>draft-ietf-ecrit-requirements-12.txt]
>
>Hi all,
>
>I am the PROTO shepherd for draft-ietf-ecrit-service-urn. You 
>can find Jon's review in the attachment. Henning published a 
>draft update. Here is the diff version:
>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/dr
>aft-ietf-ecrit-requirements-13-from-12.diff.html
>
>* Terminology: Changed "Internet Attachment Provider (IAP)" to 
>"Internet Access Provider (IAP)"; Updated "Emergency Service 
>Routing Proxy (ESRP)" 
>term
>Document is in fine shape. You may need a pass to meet current 
>I-D nits constraints introduced since it was last issued.
>
>I expected the last paragraph in Section 1 to have an 
>additional sentence saying something to the effect that the 
>latter use (displaying location information at the PSAP) is 
>orthogonal to the mapping protocol problem and the scope of 
>this document.
>
>3.2 - The term "Internet Attachment Provider" is not a common 
>one, and doesn't seem to be distinguished from the more common 
>concept of an access network. I would suggest that "access 
>network" at least be provided as a synonym in the definition.
>
>3.4 - I'm not sure what the need is to suggest that the ESRP 
>function might be performed by a B2BUA. At a high level, I 
>suppose I see the mapping client function as one that could be 
>performed by a number of entities, including entities that 
>instantiate the SIP proxy role and the SIP user agent client 
>role. I think language to that effect would be preferable to 
>suggesting that there is some motivation for pairing the 
>mapping client function with a B2BUA.
>
>In Section 6, why is Lo5 called "Validation resolution"? The 
>description of the requirement doesn't seem to relate to 
>validation or resolution, as far as I can tell. "Additional 
>Information" or something might be a better name for this requirement.
>
>In Section 8, Ma11 uses the seemingly innocuous name "URI 
>properties" to provide requirements that seem to contradict 
>Ma8. If the mapping protocol is going to return multiple PSAP 
>URIs as described in Ma11, there should be a story stronger 
>than "local policy" to meet the requirement of Ma8. You might 
>want to find a better name for Ma11 than "URI properties", too.
>

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.