Subject: [Sip] Comments on draft-ietf-sip-resource-priority-08

From: "Dale Worley" <[email-masked]>
Date: Mon, 25 Apr 2005 16:52:50 -0400

A request went out for people to read
draft-ietf-sip-resource-priority-06 with fresh eyes.  (I've since
updated this against version 08, which fixes a lot of the things I was
concerned about.) Since I'm new to the SIP world, I thought I'd try.
The disadvantage of my naivete is the terrible fear that I'm going to
bring up some issue that was discussed thoroughly in the past.  But
the old timers can probably recognize and discard such issues a lot
faster than I can search to find them, so here goes...

- Requests without the Resource-Priority: header are intended to be
processed at a lower priority than requests with a Resource-Priority:
header.  But I don't recall this being stated explicitly anywhere, and
certainly not up-front in the document.  And there seems to be no
fixed terminology for such requests.  The phrase "normal,
non-prioritized" seems to be used a lot, despite its cumbersomeness,
and the fact that it is objectively incorrect.  (Any PR actor
prioritizes *all* requests; requests without Resource-Priority: are
given the lowest priority.)

- There seems to be some ambiguity as to whether a request is
queued/delayed waiting for the resources needed to process the request
*itself*, or waiting for resources (like UA facilities, or bandwidth)
needed for the *dialog* containing the request.  This is probably not
important, as the prioritization for both sorts of resources is the
same, but it gets a bit confusing as the draft refers randomly to one
situation and then the other.  It might help to state up-front that
there can be queuing for various sorts of resources, and (absent
specific policy rules in the IANA registration) they are handled the
same way.

- There are many places where the text notes that the generic
prioritization behavior can be modified by the specific policies in
the IANA registration for the namespace.  This seems to be redundant,
and perhaps could be replaced by a single up-front statement.  This
could be augmented by a statement that the operation of a PR actor can
also be modified by local administrative policy.

- Section 3.2, "Accept-Resource-Priority" is unclear as to the
semantics of the header.  Usually, "Accept" headers describe
"configuration" information about the device which changes very
slowly.  Within that concept, I would expect that
"Accept-Resource-Priority" would list the namespaces that the RP actor
understands.  But since the definition of the header says that it
lists priority values, it must be to indicate the priorities that the
actor currently has the resources to handle.  If so, this should be
made explicit.  In this case, it seems like there needs to be an
extension of the definition to allow it to specify that
"non-prioritized" requests will be accepted.

- In section 4.6.4, "Insufficient authorization" seems to presuppose
that the RP actor can determine whether the requester is authorized to
use any particular priority.  But this seems like it is not always
true.  A better phrasing might be "... but it can determine that the
originator is not authorized ...".

- Section 4.6.5 contains the sentence fragment "If an RP actor
receives an authorized request, has insufficient resources and the
request neither preempts another request nor is queued."

- In section 4.7.2.1, it might be an improvement to say "MUST
terminate or interrupt (as appropriate) a session established".  It
seems that the range of resources that might be needed to establish a
dialog is quite broad (we've already identified signaling processing
capacity, media bandwidth, and UA facilities, and there are likely to
be more), and so we need to allow a broad range of strategies for RP
actors to free resources, with only the overriding constraint that the
higher-priority request must not be blocked from being processed by
resources consumed by a request of sufficiently lower priority.  (See
section 4.9 describe how request priorities might be grouped and
handled together.)

- In section 4.7.2.2, the last sentence might read better as "However,
the requirements in [RFC3261] regarding the frequency of provisional
messages still apply, in order to keep each session set-up active
until successful or rejected."

- Given the age of this I-D, there are likely to be implementations of
this mechanism in the field.  It would enhance the reader's interest
of these were briefly mentioned.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Apr 2005 22:03:19 -0400

Thanks for your comments. James and I will address these when we 
incorporate the IETF last call comments. Given that the draft has been 
forwarded to the IESG, it seems procedurally easiest just to treat these 
and other comments that arrived after the WGLC as IETF LC comments.

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 26 Apr 2005 10:46:46 -0400

> From: Henning Schulzrinne [mailto:[email-masked]]
> 
> Given that the draft has been 

Ah, thanks.  I don't know what the protocol is for these things.

Dale