Draft: draft-ietf-sipping-presence-scaling-requirements-00 Reviewer: Vijay K. Gurbani Pre-review comments: -------------------- The chairs had posted a note to the list asking whether or not this draft should proceed as a RFC or stay around in I-D form until the derivative drafts are done. I have no particular ax to grind here, but will note that if the sole purpose of the draft is to keep the requirements alive, there are other ways to do so. More specifically, the authors could adopt the technique of firming requirements and putting them directly in the body of the main draft as a sub-section. Alternatively, the approach taken in rfc3966 and rfc4904 could be adopted, where a section on the rationale of why certain choices were made is provided. Thus, the optimization discussion captured in this draft can still persist in the derivative draft to preserve complete context. A deciding factor on whether to make this document a stand-alone RFC could also be -- as the authors suggest -- if the requirements defined here are general ones and not ones intrinsic to SIMPLE. If they are indeed generic and applicable to any presence protocol, a stand-alone RFC is the best way to go. It does indeed appear that while the requirements are not a function of the protocol, the supporting text is so much integrated into the SIMPLE work that for all practical purposes, the requirements appear to be intrinsic to SIMPLE (to support my argument, I note that the text in S3 is full of SIMPLE lore: RLS, NOTIFY, MSRP, SUBSCRIBE, INVITE, etc.) Another reason to keep the requirements in derivative drafts is that it appears that we do not have a good handle on all of the security considerations that these requirements will elicit. And finally, it seems to me that the requirements are being fine tuned from the analysis (I could be wrong, but that is my impression when I read "The requirements are based on a separate scaling analysis document [4].") While there is nothing wrong with that, it does appear to suggest that the best place to put the requirements would then be the specific document itself. Having said that, here is the review assuming that the chairs decide the document should proceed as a RFC. ================================================================================= Draft: draft-ietf-sipping-presence-scaling-requirements-00 Reviewer: Vijay K. Gurbani Review Date: Apr-15-2008 Review Deadline: Apr-21-2008 Status: Initial review Summary: his draft is basically ready for publication, but has (many) nits that should be fixed before publication. - Abstract: suggest taking out the second sentence. It does not add much in the way of an abstract. - S3.1 - S3.4: There is uneven use of normative language. For instance, in REQ-001, is it "should not hinder" or "SHOULD NOT hinder"? In REQ-002, only NOT appears in normative markings; the obligation word (SHOULD, MUST) is missing. - S3.2: I am not sure what "Policy, Privacy, and Permissions Requirements" are doing in a scaling requirements draft. It seems that these requirements are better suited to draft-rosenberg- simple-view-sharing and draft-rosenberg-simple-intradomain-federation. - S3.3: "It is highly desirable for any presence system (intra or inter-domain) to scale linearly as number of watchers and presentities increase linearly." What happens if the watchers and presentities scale exponentially? Better to reword it so that the scalability is a function of the number of watchers and presentities (see next comment for suggested re-write.) - S3.3: This appears to be a statement rather than a requirement. A requirement could be phrased differently, viz. "Presence systems SHOULD scale according to the number of watchers and presentities in the system." - S3.3, REQ-009: Isn't "tens of millions" vague? Has any modeling been done to suggest how many average users would be in a domain? If not, I suppose you could go with "tens of millions", although as an implementor, I would say, "huh?" ;-) - S3.3, REQ-010: "It MUST support a very high level of watcher/presentity..." What do you mean by "a very high level"? A lot of messages? Or something else? - S3.3, REQ-010: "... in various intersection models." How many intersection models are there? And where are they documented? - S4, second paragraph: suggest s/Organizations need to be prepared to invest a lot in network and hardware in order to create real big systems./Organizations need to be prepared to invest substantial resources in the form of networks and hardware to create sizable systems./ - S4, third paragraph: I think it is a bit harsh to say that "The IETF tends not to think about actual deployments when designing a protocol..." Clearly, anyone that has been involved in the outbound discussions or SBC discussions can attest to the fact that the IETF does think about actual deployments. Maybe we in SIP were myopic at first, but we appear to have both of our eyes open now ;-) - S4, page 5: s/When servers is connecting to another server/When a server is connection to another server/ - S4, page 5: It is said that "When servers is connecting to another server using current protocol, there will be an extreme number of redundant messages due to the overhead of supporting UDP..." Here, are you singling out signaling over UDP because you think there will be a lot of retransmissions? If so, you may want to mention it. - S4, page 5: please expand RLS on first use. - S4, last paragraph: suggest s/considered as media as audio, video and even text messaging./ considered as media just like audio, video and even text messaging./ - S5, last paragraph: Suggest re-writing the following sentence for better readability: "The SUBSCRIBE can be extended to do similar three way handshake as INVITE and negotiate where the notify messages should go, rate and other parameters." - S5, last paragraph: s/use the SIP stack for the client/server NOTIFY/use the client/server NOTFY.