Subject: [Tsvwg] draft-ietf-tsvwg-emergency-rsvp-06.txt: Comments / Questions

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 06 Apr 2008 23:22:11 +0300

Hi all,

I read through draft-ietf-tsvwg-emergency-rsvp-06.txt and I had a few 
high-level comments/questions:

* The document is a simple extension as such. However, the challenge is 
in the architecture with respect on how to get the authorization to 
work. Don't you have to mandate a specific mechanism on how the 
authorization would work? (Don't forget that you need to address 
normadic users and roaming scenarios.) Who would do that?

* The folks who like these mechanisms most are people that have an IMS 
mindset. These guys already have defined a QoS architecture (that also 
supports similar mechanisms for priority and preemption, as far as I 
know). The same guys don't make use of RSVP. So, who would you expect to 
make use of the mechanism?

* I think the document needs to indicate clearly that this mechanism is 
supposed to be used for authority-to-authority emergency services and 
not for citizen-to-authority/authority-to-citizen emergency services.

Ciao
Hannes

---

From: ken carlberg <[email-masked]>
Date: Mon, 7 Apr 2008 10:44:07 -0400

Hannes,

> * The document is a simple extension as such. However, the challenge  
> is in the architecture with respect on how to get the authorization  
> to work. Don't you have to mandate a specific mechanism on how the  
> authorization would work?

for the time being, I'll punt the above to my co-authors.

> (Don't forget that you need to address normadic users and roaming  
> scenarios.) Who would do that?

this is rather an open question.  In what form are you considering  
"nomadic"?....at layer 2?  Or are you envisioning an underlying MIP,  
MANET, or simply a reliance of DHCP in the more classic view of  
portability?

> * The folks who like these mechanisms most are people that have an  
> IMS mindset. These guys already have defined a QoS architecture  
> (that also supports similar mechanisms for priority and preemption,  
> as far as I know). The same guys don't make use of RSVP. So, who  
> would you expect to make use of the mechanism?

personally, I can only speak at a high level in response to your  
question.  I can imagine applying the extension within some enterprise  
networks and potentially extending the signal to its leaf provider,  
wherein the signal could be manifested in other forms.  I've also seen  
the effort proposed as part of a backbone architecture integrating  
different LMR networks.

I can also envision the draft playing a complementary role in any  
symbiotic signaling used in the output from the PCN wg.  any  
discussion more specific on who would/could make use of the mechanism  
falls into potential proposals/RFPs, and there is no way I'm going  
there on this open forum :-)

> * I think the document needs to indicate clearly that this mechanism  
> is supposed to be used for authority-to-authority emergency services  
> and not for citizen-to-authority/authority-to-citizen emergency  
> services.

I would disagree.  What you are asking for would be best placed in a  
separate applicability draft.   For instance, while I mostly agree  
with your above assertion, I can also envision an exception in the  
case of Japan's 911-like service, where preferential treatment is  
supported in their PSTN for these types of many-to-1 call flows.   
Hence, more elaborate discussions on use cases and applicability is  
really best served in a different document.

cheers,

-ken

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 8 Apr 2008 12:17:45 +0200

Hi Hannes,

On 6 Apr 2008, at 22:22, Hannes Tschofenig wrote:

> Hi all,
>
> I read through draft-ietf-tsvwg-emergency-rsvp-06.txt

thanks for your review.

> and I had a few high-level comments/questions:
>
> * The document is a simple extension as such.

right.

> However, the challenge is in the architecture with respect on how  
> to get the authorization to work. Don't you have to mandate a  
> specific mechanism on how the authorization would work?

This document is focusing on the actual RSVP extension for emergency.  
An overall emergency services architecture is beyond the scope of  
that document.

The document already refers to one approach for achieving  
authorization based on RSVP-Policy +COPS:
"...along with its associated protocol suite and extensions,  
including those for policy based admission control ([RFC2753],  
[RFC2750]), for user authentication and authorization ([RFC3182]) and  
for integrity and authentication of RSVP messages ([RFC2747],  
[RFC3097])."

Another approach could be to use draft-ietf-dime-diameter-qos.  
Perhaps we should add a reference to this approach/document also?

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 10 Apr 2008 16:40:29 +0200

Hi Hannes,

>
> * I think the document needs to indicate clearly that this  
> mechanism is supposed to be used for authority-to-authority  
> emergency services and not for citizen-to-authority/authority-to- 
> citizen emergency services.

To me this is beyond the scope of this particular document (again  
focusing on an RSVP extension mechanism). This would probably pertain  
to some overall architecture/solution document for overall emergency  
services.

Francois

---

From: "Nguyen, An P" <[email-masked]>
Date: Thu, 10 Apr 2008 11:00:16 -0400

François,

I agree with you we should focus on an RSVP extension mechanism in this document. 

Regards,

An

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur IMAP
Sent: Thursday, April 10, 2008 10:40 AM
To: Hannes Tschofenig
Cc: tsvwg IETF list
Subject: Re: [Tsvwg] draft-ietf-tsvwg-emergency-rsvp-06.txt: Comments /Questions

Hi Hannes,

Francois

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 10 Apr 2008 15:24:02 -0400

I agree.

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 10 Apr 2008 15:25:44 -0400

I agree that the authorization details are out of scope for this document.

It is probably better to reference two possible approaches, rather than 
just one.

Janet

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 11 Apr 2008 11:18:13 +0200

Hi,

On 10 Apr 2008, at 21:25, Janet P Gunn wrote:
> It is probably better to reference two possible approaches, rather  
> than just one.

The following text has been added:

"
The Diameter QoS Application ([I-D.ietf-dime-diameter-qos]) allows  
network
    elements to interact with Diameter servers when allocating QoS
    resources in the network and thus, is also a possible method for
    authentication and authorization of RSVP reservations in the context
    of emergency services.
"

Francois