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

[ken carlberg <[e-mail]>]

Joel,

I'm pretty much in agreement with what Francois has said (including  
the typo :-).  more 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."

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.

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

agreed

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

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

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

agreed.  And again, thanks for the review.

-ken

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