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

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:

>  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?

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.

> 	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

>

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art