[Ieprep] comments on draft-schulzrinne-ieprep-resource-req

[Rohan Mahy <[e-mail]>]

Hi,

A few comments....

- If this becomes a working group document, I think 
draft-ietf-ieprep-sip-reqs would be a more relevant filename.  (IEPREP 
requirements for SIP)

- from the Introduction
>         3.   Resources in networks may be managed based on SIP calls.
>              (This is not always desirable or feasible due to the
>              divergence of media and signaling paths and the limited
>              ability of session setup messages to express traffic
>              characteristics, but it may be the only available mechanism
>              absent a resource reservation protocol.) In such cases,
>              policy may grant emergency preparedness or MLPP calls
>              prioritized access.
>
>         4.   In some circumstances, it may be appropriate to prioritize
>              access to signaling resources (e.g., CPU cycles) in SIP
>              proxies.
I'm not convinced that 4) is required or even technically possible for a 
proxy to give prioritized access to one SIP request over another.  Most 
of the work is already done by the time you could know the request has a 
higher priority.  Of course you can just send a "Server Unavailable 
response" to non-priority requests, but it is unclear that this reduces 
load significantly.

-Also, I think that the requirement implied in number 3 is cumbersome 
and poorly stated.
what is the requirement here?  is this a requirement that session setup 
via SIP may need appropriate QoS marked or requested?  if it is, say so 
directly.

- I think there is a requirement missing, in that some emergency service 
domains want to preempt or indicate relative priorities for native SIP 
endpoints (for example, priority of a queue operated by a hospital 
operator, preemption of "focus" on a user-oriented endpoint, or 
preemption of resources on a media mixer or conference server).  This 
could potentially use the same mechanism as 1).

> Thus, it is conceivable that the system indication can sometimes cause 
> preemption, while otherwise it just
- near the end of section 1, this sentence ends abruptly

> 2 Relationship to Emergency Call Services
>
>    The resource priority mechanisms are used to have selected
>    individuals place calls with elevated priority during times when the
>    network is suffering from an emergency-induced shortage of resources.
>    Generally, calls for emergency help placed by non-officials (e.g.,
>    "911" and "112" calls) don't need resource priority under normal
>    circumstances.  If such emergency calls are placed during emergency-
>    induced network resource shortages, the call identifier itself is
>    sufficient to identify the emergency nature of the call. Adding an
>    indication of resource priority may be less appropriate, as this
>    would require that all such calls carry this indicator. Also, it
>    opens another attack mechanism, where non-emergency calls are marked
>    as emergency calls. (If the entity can recognize the request URI as
>    an emergency call, it would not need the resource priority
>    mechanism.)
- perhaps there is a requirement to create an "ordinary emergency 
services" class of priority?  I don't have a strong feeling about this, 
but it seems reasonable.

- the security requirements are WAY underspecified.

thanks,
-rohan mahy

(SIPPING co-chair)