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

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

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

> 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