Subject: [Sip] Re: ETF LC review: draft-ietf-sip-resource-priority-09

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jun 2005 16:09:53 -0400

[This is a general area review.  This review of draft .9 is intended as 
early review for the IESG consideration.
  Details on the general area review team can be found at 
http://www.alvestrand.no/ietf/gen/art/review-guidelines.html
  The reviewer apologizes for not getting these minor comments to the 
relevant parties sooner.]

This document appears ready for publication as a Proposed Standard.  There 
are some minor matters that ought to be attended to.

Section 4.7.1.1 states that "A UAC in an administrative domain that employs 
preemption MUST ..."  I know what administrative domains usually mean, but 
it seems likely that in this case there may be at least three different 
administrative domains that the UAC is "in".  There is the IP domain at and 
near the originating UAC which may have SIP Proxies (either mandated by 
policy or transparently inserted.)  There is the domain of the subscribers 
chosen outbound proxy (if any), and there is the domain of the destination 
UAC.  There may be other domains along the signaling path.  Given the 
multiplicity of domains, and that a client may change domains, one of two 
things seems necessary.
Preferably, just require that ALL UACs supporting this RFC be prepared to 
receive the BYE with sipping reason ....  This does not seem onerous, and 
does seem to solve the issue.
Alternatively, the text needs a clear explanation of what "administrative 
domain" is meant and how a UAC would know whether to be prepared to receive 
the error indication.  Given the difficulty of building client software for 
specific administrative domains, this seems a doubtful choice.

Joel M. Halpern

----
TRANSPORT
     Communications Resource Priority for the Session Initiation Protocol(SIP),
          for Proposed Standard
     draft-ietf-sip-resource-priority-09
AD: Allison Mankin
Reviewer: Joel M. Halpern

_______________________________________________
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: Sat, 25 Jun 2005 21:01:11 -0400

Joel:

thanks for taking the time to review the draft. I agree that words like 
"administrative domain" can be interpreted in multiple ways, 
particularly in the multi-hop cases you mention. (Many of the 
participants in the discussion tend to assume that R-P operates in 
relatively closed environments where this would not be a concern, in 
that UAC, UAS and proxies would be administered by the same authority.)

To address your comment: Since the Reason header causes no protocol 
state transitions, ANY UAC 'must (will) be prepared to receive it' 
(since there are no preparations to be taken - ignoring it will work 
just fine). The header really only makes sense here if the UAC requested 
a resource value that can cause preemption. Thus, I would reword the 
nettlesome sentence as something like

"A UAC that requests a priority value that may cause preemption MUST 
understand a Reason header field in the BYE request explaining why the 
session was terminated, as discussed in []."

If nobody objects, I will replace the sentence.

Henning

Joel M. Halpern wrote:

> Section 4.7.1.1 states that "A UAC in an administrative domain that 
> employs preemption MUST ..."  I know what administrative domains usually 
> mean, but it seems likely that in this case there may be at least three 
> different administrative domains that the UAC is "in".  There is the IP 
> domain at and near the originating UAC which may have SIP Proxies 
> (either mandated by policy or transparently inserted.)  There is the 
> domain of the subscribers chosen outbound proxy (if any), and there is 
> the domain of the destination UAC.  There may be other domains along the 
> signaling path.  Given the multiplicity of domains, and that a client 
> may change domains, one of two things seems necessary.
> Preferably, just require that ALL UACs supporting this RFC be prepared 
> to receive the BYE with sipping reason ....  This does not seem onerous, 
> and does seem to solve the issue.
> Alternatively, the text needs a clear explanation of what 
> "administrative domain" is meant and how a UAC would know whether to be 
> prepared to receive the error indication.  Given the difficulty of 
> building client software for specific administrative domains, this seems 
> a doubtful choice.
> 
> 
> Joel M. Halpern
> 
> ----
> TRANSPORT

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jun 2005 21:21:22 -0400

That would take care of my problems with the sentence.

Thank you,
Joel

At 09:01 PM 6/25/2005, Henning Schulzrinne wrote:
>"administrative domain" can be interpreted in multiple ways, particularly 
>in the multi-hop cases you mention. (Many of the participants in the 
>discussion tend to assume that R-P operates in relatively closed 
>environments where this would not be a concern, in that UAC, UAS and 
>proxies would be administered by the same authority.)
>
>To address your comment: Since the Reason header causes no protocol state 
>transitions, ANY UAC 'must (will) be prepared to receive it' (since there 
>are no preparations to be taken - ignoring it will work just fine). The 
>header really only makes sense here if the UAC requested a resource value 
>that can cause preemption. Thus, I would reword the nettlesome sentence as 
>something like
>
>>domain at and near the originating UAC which may have SIP Proxies (either 
>>mandated by policy or transparently inserted.)  There is the domain of 
>>the subscribers chosen outbound proxy (if any), and there is the domain 
>>of the destination UAC.  There may be other domains along the signaling 
>>path.  Given the multiplicity of domains, and that a client may change 
>>domains, one of two things seems necessary.
>>domain" is meant and how a UAC would know whether to be prepared to 
>>receive the error indication.  Given the difficulty of building client 
>>software for specific administrative domains, this seems a doubtful choice.
>>
>>Joel M. Halpern
>>----
>>TRANSPORT