Draft: draft-ietf-sip-resource-priority-09 Reviewer: Joel Halpern Date: Saturday 6/25/2005 3:10 PM CST(with Author's comments agreed on Saturday 6/25/2005 8:21 PM) Summary: This document appears ready for publication as a Proposed Standard. Review Comments: 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. Author's Response: 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.