Subject: [Gen-art] [Gen-Art] LC Review: draft-ietf-tsvwg-emergency-rsvp-07.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 03 May 2008 18:09:19 -0400

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
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.

Document: Resource ReSerVation Protovol (RSVP) Extensions for
               Emergency Services
Reviewer: Joel M. Halpern
Review Date: 3-May-2008
IETF LC End Date: 9-May-2008
IESG Telechat date: N/A

Summary:  This document is ready for publication as a proposed standard.
The reviewer would appreciate feedback on the minor items listed below.

Comments:
Slight Concern:
	The Application Resource Priority numerical values used by this RFC are 
the ones assigned for SIP usage.  I have no problem with the reuse of 
the name spaces and priorities.  My concern is that someone looking for 
documentation on the resource priority values for this may have 
difficulty realizing that they MUST look at the SIP tables, even for 
non-SIP based emergency communication.  Is there any way to cause there 
to be a pointer in the RSVP portion of the registry to the SIP RPH registry?

Question:
	Should this document include some explanation of what the PDP is to do 
when given multiple ALRP elements which it understands?  For that 
matter, should there be explicit text saying that the PDP can ignore any 
ALRPs whose namespace the PDP does not understand?

Minor Comments:
	My personal opinion is that using "call" to describe the sessions being 
established is probably not the best choice.  In many contexts which 
will need to reference this document, call has a much more specific 
meaning.  It is not clear why "session" is not sufficient.  (But I 
presume that the particular terminology is the result of significant 
consideration, and therefore my personal reaction is not a reason to 
hold up this document.)
	It seems very odd that the format of the Admission Priority Policy 
Element has 32 consecutive reserved bits.  It will work as written, and 
I presume that there was a reason.

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

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 5 May 2008 15:38:16 +0200

Hello Joel,

Thank you for your review. Please find my thoughts below on the items  
you brought up.

On 4 May 2008, at 00:09, Joel M. Halpern wrote:

> 	The Application Resource Priority numerical values used by this  
> RFC are the ones assigned for SIP usage.  I have no problem with  
> the reuse of the name spaces and priorities.  My concern is that  
> someone looking for documentation on the resource priority values  
> for this may have difficulty realizing that they MUST look at the  
> SIP tables, even for non-SIP based emergency communication.  Is  
> there any way to cause there to be a pointer in the RSVP portion of  
> the registry to the SIP RPH registry?

We could potentially do this. I do not have a strong opinion, but I  
actually have an inclination for doing so. My rationale is:
	* since the SIP RPH registry is explicitly referenced by the text  
describing the Application-Level Resource Priority element, I think  
folks trying to implement this should realize this is where they  
should look
	* i think in general, to find out values for an information element,  
people first look at the document specifying the information element  
as opposed to browsing the set of registries for the corresponding  
protocol
	* I wonder if creating a second registry under RSVP just to point to  
the SIP RPH registry would not creating more confusion than help.
But I am open and if folks prefer that approach, that is fine by me.

>
> Question:
> 	Should this document include some explanation of what the PDP is  
> to do when given multiple ALRP elements which it understands?  For  
> that matter, should there be explicit text saying that the PDP can  
> ignore any ALRPs whose namespace the PDP does not understand?

Section 3.3 of the document discusses situations where the PDP does  
not understand the ALRP Policy Element. Where the PDP understands the  
Policy Element, then I'm thinking that the policy decision  
implemented by the PDP should be completely open. This includes when  
the PDP does not recognize an ALRP namespace or when there are  
multiple ALRPs. I see this as a policy to be decided by the network  
administrator and doubt we can mandate a behavior that would apply  
universally for all networks.

>
> Minor Comments:
> 	My personal opinion is that using "call" to describe the sessions  
> being established is probably not the best choice.  In many  
> contexts which will need to reference this document, call has a  
> much more specific meaning.  It is not clear why "session" is not  
> sufficient.  (But I presume that the particular terminology is the  
> result of significant consideration, and therefore my personal  
> reaction is not a reason to hold up this document.)

The rationale was that people were often more familiar with the  
concept of "emergency" being associated to phone calls than to  
multimedia sessions. So it helped initially to use the term "call".  
We included a clarification note explaining that "call" actually  
means "session".
"Note: Below, this document references several examples of IP
    telephony and its use of "calls", which is one form of the term
    "sessions" (Video over IP and Instant Messaging being other examples
    that rely on session establishment).  For the sake of simplicity, we
    shall use the widely known term "call" for the remainder of this
    document.
"
Now that the document has matured enough, I would be happy to revert  
to a more generic "session" terminology. let's hear my co-authors on  
this.

> Element has 32 consecutive reserved bits.  It will work as written,  
> and I presume that there was a reason.
>

Yes, that was discussed. I remember in particular there was a request  
to have room for potential growth (in particular for Adm Priority  
value).

Cheers

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 5 May 2008 16:11:24 +0200

Correcting a typo below:

On 5 May 2008, at 15:38, Francois Le Faucheur IMAP wrote:

> Hello Joel,
>
> Thank you for your review. Please find my thoughts below on the  
> items you brought up.
>
>> there any way to cause there to be a pointer in the RSVP portion  
>> of the registry to the SIP RPH registry?
>
> actually have an inclination for doing so.

This should read : "but I actually have an inclination for _not_  
doing so."
Francois

> My rationale is:
> 	* i think in general, to find out values for an information  
> element, people first look at the document specifying the  
> information element as opposed to browsing the set of registries  
> for the corresponding protocol
> 	* I wonder if creating a second registry under RSVP just to point  
> to the SIP RPH registry would not creating more confusion than help.
> not understand the ALRP Policy Element. Where the PDP understands  
> the Policy Element, then I'm thinking that the policy decision  
> implemented by the PDP should be completely open. This includes  
> when the PDP does not recognize an ALRP namespace or when there are  
> Now that the document has matured enough, I would be happy to  
> revert to a more generic "session" terminology. let's hear my co- 
> authors on this.
>
>
>> 	It seems very odd that the format of the Admission Priority  
>> Policy Element has 32 consecutive reserved bits.  It will work as  
>> written, and I presume that there was a reason.
>>
>
> Yes, that was discussed. I remember in particular there was a  
> request to have room for potential growth (in particular for Adm  
> Priority value).
>
> Cheers
>
> Francois
>
>>
>

---

From: ken carlberg <[email-masked]>
Date: Mon, 5 May 2008 10:46:44 -0400

Joel,

I'm pretty much in agreement with what Francois has said (including  
the typo :-).  more below...

> This should read : "but I actually have an inclination for _not_  

I'd rather have this document point to the right registry instead of  
going in reverse and having the registry be a pointer to someplace else.

>> universally for all networks.

agreed

>> revert to a more generic "session" terminology. let's hear my co- 

I'm fine with this.  and in going back to the more generic "session",  
we may simply want to do a total inversion of text.  where we start  
with "session" and stay with it through the entire document, but note  
in the Intro that a more specific instance of a session could be in  
the form of a "call".

>> request to have room for potential growth (in particular for Adm  

agreed.  And again, thanks for the review.

-ken

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 7 May 2008 09:35:11 +0200

Hi Joel,

>
>>>>
>>>> Minor Comments:
>>>> 	My personal opinion is that using "call" to describe the  
>>>> sessions being established is probably not the best choice.  In  
>>>> many contexts which will need to reference this document, call  
>>>> has a much more specific meaning.  It is not clear why "session"  
>>>> is not sufficient.  (But I presume that the particular  
>>>> terminology is the result of significant consideration, and  
>>>> therefore my personal reaction is not a reason to hold up this  
>>>> document.)
>>>
>>> multimedia sessions. So it helped initially to use the term  
>>> "call". We included a clarification note explaining that "call"  
>>> actually means "session".
> I'm fine with this.  and in going back to the more generic  
> "session", we may simply want to do a total inversion of text.   
> where we start with "session" and stay with it through the entire  
> document, but note in the Intro that a more specific instance of a  
> session could be in the form of a "call".
>>>

We have agreement among co-authors, so next version will address your  
comment and :
	- use "session" throughout
	- have a note saying that a "call" is a more specific instance of a  
session.

Thanks

Francois

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 May 2008 15:46:11 -0400

The -07 version of this document was acceptable.  THe -08 includes 
revisions to address some minor comments from me, as well as other 
improvements.  It is ready for publication as a Proposed Standard.

Yours,
Joel M. Halpern