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

From: Rohan Mahy <[email-masked]>
Date: Fri, 28 Jun 2002 12:23:10 -0700

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)

---

From: Ken Carlberg <[email-masked]>
Date: Sun, 30 Jun 2002 11:29:04 +0100

> via SIP may need appropriate QoS marked or requested?  if it is, say so 

as I read the draft, items 1 through 4 of the Introduction seemed more 
aimed at providing motivation for the R-P mechanism, as opposed to
requirements.  after points 1-4, actual requirements are stated.  one
thing that may help is to divide the Intro section into two parts:
1. Introduction, and 2. Requirements

> - the security requirements are WAY underspecified.

would it be possible to simply point to Ian Brown's draft
<draft-ietf-ieprep-security-01.txt> and expand it if necessary to address 
the security concerns you may have?   my personal view is that I would be 
a bit weary of placing a lot of security work in a requirements doc 
for a labeling mechanism.  mind you, I'm not saying that security is
a non-issue (actually, its quite critical).  but I think because we have 
a number of drafts that need to address the subject, it would be easier to 
have consensus on a single document as opposed to trying to replicate in 
detail security requirements/issues in each and every document.

my 2 cents,

-ken

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Sun, 30 Jun 2002 13:33:42 -0700

Ken,

You make an excellent point. If we were to attempt to replicate in
detail security requirements/issues in each and every document, it is likely
that the text would be slightly different as the security requirements
evolved. By pointing to a single source one avoids the unintended differences.