[Sipping] WG review of draft-ietf-sipping-presence-scaling-requirements-01

["Vijay K. Gurbani" <vkg at alcatel-lucent.com>]

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.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg at {alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP