Subject: [Ecrit] WGLC on draft-ietf-ecrit-framework-05

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 02 Mar 2008 19:54:28 +0200

This is a Last Call for comments on 
http://tools.ietf.org/html/draft-ietf-ecrit-framework-05

Because of the timing of the impending IETF meeting and the interactions 
with other SDOs, we are setting the call for **4 weeks**.

Please have your comments in no later than March 30.

Do remember to send a note in if you have read the document and have no 
other comments other than
"its ready to go" - we need those as much as we need "I found a problem".

Thanks!
Hannes & Marc

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

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Fri, 21 Mar 2008 15:30:02 +0100

I read through the document and here are my comments:

page 7: "The phone gets location from the DHCP server in civic
[RFC4676] or geo" -> should it be "and/or"?

page 8: second bullet: it is not obvious to me that the refreshing of
the mapping is meant (sounds rather like initial determination).  And
there should be another bullet above saying that location information
is refreshed too (as indicated in the figure below and discussed below
in the text).

page 9: second bullet: "In this flow, DHCP is used as an example
location configuration protocol (LCP)" - I can't find anything in the
example above that mentions DHCP, and I don't think Figure 1 and 2
have any special consideration for DHCP. Is it necessary to restrict
this example to DHCP?

page 10: "The LoST response may contain the dial string for emergency
calls appropriate for the location provided."
Just a MAY for the dialstring? The dialstring is mandatory for
detecting an emergency call (although it is an optional element in
LoST).

page 15: "... as a point (geo or civic) or polygon." What is a "civic
point"? I would suggest "geo point or polygon or civic location".

page 27: "create SIP INVITE messages with the Service URN in the
Request URI" - The To: header is not mentioned here.

editorial:

page 3: Dispatch Location: ... "easily locate the callee" - should be: "caller"

page 7: "to a set of PSAP or URIs" -> PSAP URIs

page 13: "routing is but one of two uses..."

page 22: "it make take some time"

page 23: Missing reference: "Handling multiple locations is discussed in ."

cheers
karl heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Mar 2008 10:41:04 -0400

Thanks a lot for your comments.  I agree with all of your comments except
the page 10 LoST return of dialstring may/must.  I don't think it's possible
to make it MUST because there are systems such as 3GPP that work without it.
I could see a SHOULD, where the exception is a closed system where the LoST
operator knows for certain that all devices that query it have the correct
dial string via some other mechanism.

Henning, does that sound about right to you?

Karl, would that address your issue?

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Karl Heinz Wolf
Sent: Friday, March 21, 2008 10:30 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05

editorial:

page 3: Dispatch Location: ... "easily locate the callee" - should be:
"caller"

cheers
karl heinz

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Fri, 21 Mar 2008 15:52:30 +0100

>  LoST dialstring may/must/should

we already had a discussion on this topic when I read "framework-03" -
I just wanted to preserve this topic from falling into oblivion.
I would suggest to note somewhere in what cases the LoST server is
expected to return the dialstring and in what situation it is not
necessary.

cheers
karl heinz

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Mar 2008 11:05:43 -0400

> Henning, does that sound about right to you?

I'm ok with documenting a clear exception, but I wonder whether there  
is harm in requiring that LoST always returns the dial string, for  
several reasons:

- You never know who will connect to a server, even if you believe  
that it can only be accessed from within a certain physical network.  
This also tends to change over time; upgrading servers and data sets  
at that time seems more error-prone, easy to forget and painful.

- It doesn't seem particularly onerous to include this information.  
It's not secret, it's not hard to maintain and it doesn't change.

- Longer term, IMS may get more open (see Verizon...), so it may be  
harder to make the distinction.

- It seems difficult to describe the exception in a way that covers  
what we want without encouraging "bad" behavior.

Thus, I think interoperability and robustness argue for MUST. If  
certain specialized systems end up ignoring the information in favor  
of local configuration, that's a separate problem. Given that  
disagreement over the dialstring seems unlikely and obvious, I'd  
rather have two sources than none.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Mar 2008 12:26:27 -0400

Anyone else on the list have a problem in making this a must (small must in
framework, MUST in phonebcp)?

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, March 21, 2008 11:06 AM
To: Brian Rosen
Cc: 'Karl Heinz Wolf'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05

Henning

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 21 Mar 2008 12:48:13 -0400

I think it's a good thing to have it as MUST in bcp. 
Barbara 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Friday, March 21, 2008 12:26 PM
To: 'Henning Schulzrinne'
Cc: [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05

Anyone else on the list have a problem in making this a must (small must
in
framework, MUST in phonebcp)?

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, March 21, 2008 11:06 AM
To: Brian Rosen
Cc: 'Karl Heinz Wolf'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05

Henning

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 22 Mar 2008 19:48:34 -0500

I agree with it being a MUST.

With respect to the comment " there are systems such as 3GPP that work  
without it." I think the correct positioning is that those are not ECRIT
systems - they are systems defined for more closed network scenarios
that are not applicable to the general scope that ECRIT addresses. Those
systems can call out their own criteria - and, really, their
specifications are the correct place to identify exceptions to ECRIT
rules if that's what they see fit.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stark, Barbara
Sent: Saturday, 22 March 2008 3:48 AM
To: Brian Rosen; Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05

-----Original Message-----

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, March 21, 2008 11:06 AM
To: Brian Rosen
Cc: 'Karl Heinz Wolf'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-framework-05

Henning

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA623

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]