Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 9 May 2006 10:03:30 -0400

>From the peanut gallery:

Ma17 and Ma5 still seem to be in conflict.  If my contact protocol is
SIP, how many SIP contacts will be provided overall?  Ma17 says 1.  Ma5
says there can be primary and alternate, that is 2.  So, is it 1 or 2,
or perhaps more if there are multiple overlapping police forces?

Another thing.  SIP has a Contact header.  Is contact and Contact the
same thing?

It seems like this is saying:

Multiple URIs may be returned because there are multiple agencies to
target.

Each agency may use multiple protocols.

For each protocol an agency might use, there may be a primary and an
alternate URI.

Each URI may contain ancillary properties to provide information on its
usage.

It not, I can't tell from the words what is intended.

Mike

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Tuesday, May 09, 2006 3:12 AM
> To: Roger Marshall; Ted Hardie; Hannes Tschofenig; 
> [email-masked]; Henning Schulzrinne
> Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt
> 
> Roger,
>  
> this is much better now.
>  
> IMHO the issue could still be slightly improved:
>  
> In Ma5 we are talking about an alternate contact and a primary contact
>  
> It should be clearly stated in Ma17 that we talk here about 
> the primary contact:
>  
> Sugestion: Change Ma17 from:
>  
> Ma17.  Single URI per contact protocol: Though there is 
> support for multiple URIs being returned, the mapping 
> protocol SHOULD return only one URI per contact protocol 
> used, so that clients are not required to select among 
> different targets for the same contact protocol
>  
> to:
>  
> Ma17.  Single primary URI per contact protocol: Though there 
> is support for multiple URIs being returned, the mapping 
> protocol SHOULD return only one explicitely marked primary 
> URI per contact protocol used, so that clients are not 
> required to select among different targets for the same 
> contact protocol
>  
> regards
> Richard
> 
> ________________________________
> 
> Von: Roger Marshall [mailto:[email-masked]]
> Gesendet: Di 09.05.2006 01:29
> An: Stastny Richard; Ted Hardie; Hannes Tschofenig; 
> [email-masked]; Henning Schulzrinne
> Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt
> 
> 
> 
> Ok, based on the points Richard made, and Ted's suggestions, 
> and other than some slight ordering changes (Ma4 still first, 
> then Ma17, since the latter has a referenced qualification 
> pointing to the former), and some minor rewording for 
> read-ability, here's the resulting clump of requirements 
> which we were talking about:
> 
> ...
> 
> Ma4.  Multiple response URIs: The mapping protocol MUST allow 
> multiple URIs to be inclued in a mapping response.
> 
> Motivation: Multiple URIs may be available from the mapping server.
> 
> Ma17.  Single URI per contact protocol: Though there is 
> support for multiple URIs being returned, the mapping 
> protocol SHOULD return only one URI per contact protocol 
> used, so that clients are not required to select among 
> different targets for the same contact protocol.
> 
> Motivation:  There may be two or more URIs returned when 
> multiple contact protocols are available (e.g., SIP and SMS). 
>  The client may select among multiple contact protocols based 
> on its capabilities, preference settings, or availability.
> 
> Ma5.  URI alternate contact: In addition to returning a 
> primary contact, the mapping protocol MUST support the return 
> of a URI or contact method explicitly marked as an alternate 
> contact for use when
> 
> a fallback contact is needed.
> 
> Motivation:  In response to a mapping request, the mapping 
> server may return an alternate URI.  Implementation details 
> to be described within an operational document.
> 
> Ma6.  URL properties:"> The mapping protocol MUST support the 
> ability to provide ancillary information about a contact or 
> URI that allows the mapping client to determine relevant 
> properties of the URL.
> 
> Motivation: In some cases, the same geographic area is served 
> by several PSAPs, for example, a corporate campus might be 
> served by both a corporate security department and the 
> municipal PSAP. The mapping protocol should then return URLs 
> for both, with information allowing the querying entity to 
> choose one or the other.  This determination could be made by 
> either an ESRP, based on local policy, or by direct user 
> choice, in the case of caller-based methods.
> 
> ...
> 
> Out-of-order numbering left for reference.  These will be 
> renumbered in next draft vers.
> 
> -roger.
> 
> 
> >-----Original Message-----
> >From: Stastny Richard [mailto:[email-masked]]
> >Sent: Saturday, May 06, 2006 12:55 PM
> >To: Ted Hardie; Hannes Tschofenig; [email-masked]; Henning 
> Schulzrinne; 
> >Roger Marshall
> >Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt
> >
> >>To make that clear, I suggest
> >>we move Ma17 up to be before Ma4, and we change "URI
> >alternate contact"
> >>to say "explicitly marked as an alternate contact for use when a 
> >>fallback contact is needed".
> >
> >Yes, thank you for the clarification, this would clarify the issue
> >
> >Richard
> >
> >
> >________________________________
> >
> >Von: Ted Hardie [mailto:[email-masked]]
> >Gesendet: Sa 06.05.2006 21:14
> >An: Stastny Richard; Hannes Tschofenig; [email-masked]; Henning 
> >Schulzrinne; Roger Marshall
> >Betreff: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt
> >
> >
> >
> >At 7:09 PM +0200 5/6/06, Stastny Richard wrote:
> >>IMHO there is a contradiction, (espeially between Ma6 and
> >Ma17) or at
> >>least this is very confusing. I do not know now if multiple 
> URIs for 
> >>the same contact protocol are allowed or not)
> >>
> >>In one requirement  the client needs to the select among differnt 
> >>protocols, in the other not
> >>
> >>Richard
> >
> >I agree that this is a bit confusing, largely because Ma17 
> occurs after 
> >the others.  I think if we moved it forward, it would make 
> more sense, 
> >as it would then imply that the multiple URIs  in Ma4 were 
> each from a 
> >different scheme.
> >
> >The reason we did not want to return multiple contact URIs 
> for a single 
> >scheme in a standard response was that we didn't want the client to 
> >have to worry about which of the returned URIs to pick 
> (e.g., if I gave 
> >you six SIP URIs, which one should be selected?).
> >
> >The alternate contact field allowed you to handle the need 
> for explicit 
> >indication of a fallback, but with the understanding that the client 
> >didn't need to determine an ordering in the response--the 
> fallback was 
> >there only when the first contact was not available.
> >
> >That's my memory of how we got there.   To make that clear, I suggest
> >we move Ma17 up to be before Ma4, and we change "URI 
> alternate contact" 
> >to say "explicitly marked as an alternate contact for use when a 
> >fallback contact is needed".
> >                        regards,
> >                                Ted
> >
> >
> >>
> >>Ma4.  Multiple response URIs: The mapping protocol MUST support the
> >>      possible inclusion of multiple URIs in a mapping response.
> >>      Motivation: Multiple URIs may be available from the mapping
> >>      server.
> >>
> >>   Ma5.  URI alternate contact: In addition to returning a primary
> >>      contact, the mapping protocol MUST support the return
> >of a URI or
> >>      contact method explicitly marked as an alternate contact.
> >>      Motivation: In response to a mapping request, the 
> mapping server
> >>      may return an alternate URI.  Implementation details to be
> >>      described within an operational document.
> >>
> >>   Ma6.  URL properties: The mapping protocol MUST support 
> the ability
> >>      to provide ancillary information about a contact or URI that
> >>      allows the mapping client to determine relevant
> >properties of the
> >>      URL.
> >>      Motivation: In some cases, the same geographic area 
> is served by
> >>      several PSAPs, for example, a corporate campus might be
> >served by
> >>      both a corporate security department and the municipal
> >PSAP.  The
> >>      mapping protocol should then return URLs for both, with
> >>      information allowing the querying entity to choose one or the
> >>      other.  This determination could be made by either an
> >ESRP, based
> >>      on local policy, or by direct user choice, in the case
> >of caller-
> >>      based methods.
> >>
> >>   Ma17.  Single URI per contact protocol: Though the 
> mapping protocol
> >>      supports the return of multiple URIs, it SHOULD 
> return only one
> >>      URI per contact protocol, so that clients are not required to
> >>      select among different targets for the same contact protocol.
> >>      Motivation: There may be two or more URIs returned 
> when multiple
> >>      contact protocols are available (e.g., SIP and SMS).  
> The client
> >>      may select among multiple contact protocols based on its
> >>      capabilities, preference settings, or availability.
> >>
> >>_______________________________________________
> >>Ecrit mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> >
> >
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 May 2006 08:30:16 -0700

>or perhaps more if there are multiple overlapping police forces?

I think you're making this harder than you need to.  If I send a
query requesting the contact URIs for a specific service based on
my location, I get back one URI per scheme.  I may also get
back a URI explicitly marked as a fallback, for use only if I cannot
use the usual contact URIs received (or if I try them and they fail).
So you might get one geographically appropriate SIP URI, one geographically
appropriate SMS URI, and one geographically appropriate XMPP URI.
The fallback SIP URI (if present) is not necessarily as geographically
appropriate; it might point to something like a state-wide response
center.

Frankly, I think we've wordsmithed this enough.  Much more effort
will not produce better instructions to the protocol designers.
			regards,
				Ted Hardie

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 9 May 2006 11:53:40 -0400

Huh, I would have thought that you could get a fallback URI per scheme

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Tuesday, May 09, 2006 11:30 AM
To: Michael Hammer (mhammer); Stastny Richard; Roger Marshall; Hannes
Tschofenig; [email-masked]; Henning Schulzrinne
Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt

---

From: Shida Schubert <[email-masked]>
Date: Mon, 15 May 2006 15:04:08 -0700

It's good that one can obtain primary and backup URIs,
and I personally think the text has really improved.

It's not really related but this thread had made me think
of a situation where there is a regional disaster or regional
scale DoS attack and both primary and backup URIs given
by LOST is not reachable? What would happen then?

Until propagation is completed to change the data in
the database that URIs in the region is not reachable,
I am assuming that LOST will always provide the same
URI A for the locations A. Thus client will not be able to
reach the PSAPs. And because LOST is not stateful
it will not provide client with different set of URIs on
its second attempt.

This might be a deployment/implementation matter
and might not be a protocol requirement and I might be
the only one concerned, but because LOST is decoupled
from the signaling path, it might be good to have a way
for LOST clients to request a URI with a list of URIs that
it does not want to receive as a resolutions.

example:
Please provide me with URIs for service A given my location
is A but don't provide me with URI A or URI B.

Regards
Shida Schubert

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 15 May 2006 18:41:58 -0400

Please don't confuse the determination of the appropriate PSAP URI from the
resolution of that URI.  In most cases, it will probably be best to change
the resolution of a URI rather than change the LoST database.

I do think it is vital to be able to change the database on short notice,
primarily because in disasters, things never go the way you expect, and thus
not depending on mapping remaining constant is not a good idea.  I do
however think that changing the resolution of the URI is more likely to be
used to recover from an "under attack" PSAP.  

I do think getting back a list of secondary URIs (with a q-value) could be
useful, but I don't think it's an absolute requirement.

I'm not thrilled with "these didn't work, have you got any more?"

Brian

-----Original Message-----
From: Shida Schubert [mailto:[email-masked]] 
Sent: Monday, May 15, 2006 6:04 PM
To: Ted Hardie
Cc: [email-masked]; Stastny Richard
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt

example:

Regards
Shida Schubert