Draft: draft-ietf-sipping-config-framework-12.txt Reviewer: David Robbins [robbins.dave@verizon.net] Review Date: 7/8/2007 Review Deadline: 7/9/2007 (extended original WGLC date from 6/25/2007) Status: WGLC Summary: Needs work. Comments: --------- Speaking from some implementation experience with the framework (as it was defined about two years ago), although speaking up very late in the game (severe time constraints prevented me from participating in this discussion before now), I have some comments and suggestions on the -12 draft. The complexity of this is more or less unavoidable, given the variety of deployment scenarios that the framework is intended to address, and credit is due to the contributors who have worked this almost to death over the years. And I generally like how this has evolved since we took our snapshot two years ago. Nevertheless, as other commenters have noted, there still seem to be some rough spots. To begin with, I tend to concur with many of John Elwell's comments, particular as they relate to the difficulty in reading and understanding the draft. In fairness, this is due in part to the inherent complexity of the framework in its need to cater to several widely disparate deployment scenarios. It is a real challenge to describe the framework in terms that are easy to understand and at the same time sufficiently precise to specify clear and unambiguous requirements. While the meaning and technical content of the draft is fairly clear to me, I can see some room for improvement. At the cost of making the draft larger, a few more use cases might be helpful in justifying the complexity. (I'm not totally sure about this, and have none to suggest at the moment.) The state diagram on page 30 fails to recognize the possibility that the NOTIFY may arrive before the 2XX, that the NOTIFY may arrive but the 2XX may never be received, or that the NOTIFY may signal the termination of the subscription (in which case it says nothing about the corresponding profile document). There are various race conditions involving the 2XX and NOTIFY responses to a SUBSCRIBE and retransmissions of the SUBSCRIBE, but they are generally resolved simply by carefully following the procedures specified by RFC 3261, RFC 3263, and RFC 3265. Regarding the discussion of timeouts on page 31, IIRC HTTP and HTTPS do not specify timeouts, leaving it up to the client to decide when to declare a request timeout. The draft should explicitly require the UA to set a timeout on an HTTP/HTTPS request; the timeout should probably be in the range of 30-60 seconds. Also, RFC 3265 does not address the situation where a SUBSCRIBE elicits a 2XX response but not the mandatory NOTIFY. The draft should require the UA to set a NOTIFY timeout upon sending the SUBSCRIBE; a value perhaps somewhat larger than 64*T1 would be appropriate. I found the pseudocode on page 32 somewhat hard to read, as it is a format I've never seen before. Not wholly unreadable, though. One nit -- the use of "Abort this function" to mean "success" is jarring, because "abort" generally connotes failure. I agree with the principle of exponential backoff, but I'm uncomfortable with starting at 64*T1 and limiting to eight retries. In at least some circumstances, you want the client to autonomously continue retrying indefinitely, you may want to start at something more like one minute, and you may want to cap it at something like 30 minutes or an hour. I would also recommend that a retry be directed to an alternate server only if no response at all was received from one server. One can generally assume that if one server out of a set of servers returned for a given domain name returns an error response, all other servers will return the same error response, since they are all peers and should be interchangeable. A response shows that the server is alive, but doesn't like the request, whereas a timeout means that the server may be dead or severely overloaded, in which case an alternate server is likely to respond successfully. On page 40, I'm puzzled by the notion that the notifier may be "unsure" whether the NOTIFY is expected to contain profile contents. Since the notifier by definition is responsible for sending the NOTIFY, it presumably knows what it will be sending. At least I'd like to think this is more or less deterministic. :-) To protect the notifier against attacks and to prevent disclosure of even seemingly innocuous information to an attacker, the notifier should always authenticate the SUBSCRIBE, regardless of what will be sent in the NOTIFY, except in the case noted, where the notifier is explicitly configured to accept requests from subscribers that do not possess credentials. In most cases that I can imagine, you want to accept subscriptions only from credentialed subscribers. For protection of profile content, you generally want to deliver it via content indirection and HTTPS, so that the requestor must authenticate the actual retrieval request and so that you have integrity protection over the content. You could use direct content if your NOTIFY is sent over a known secure channel (i.e. TLS or IPsec all the way between UA and PDS). Although this draft defers for future consideration a mechanism by which the UA can complain to the PDS or PCC about a malformed profile document, it turns out in practice that such a capability is incredibly important. Unless you have an alternate "debug" interface to the device, diagnosing a malformed profile document is a major, major PITA. I don't have a solution to propose, but if we could think of something fairly straightforward, it would be worth including in the draft. Many of my comments above are made against what is largely descriptive text in section 6, so to the extent that these comments are address in a revision of the draft, normative text will be impacted as well.