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

From: Avshalom Houri <[email-masked]>
Date: Thu, 3 Jul 2008 19:34:45 +0300

Vijay,

Many thanks for the comments and the review.
Comments below.

Sorry for the late response.

--Avshalom

"Vijay K. Gurbani" <[email-masked]> wrote on 16/04/2008 01:42:09:

> "Vijay K. Gurbani" <[email-masked]> 
> 16/04/2008 01:42
> 
> To
> 
> Avshalom Houri/Haifa/IBM@IBMIL, [email-masked], 
> [email-masked], [email-masked], [email-masked]
> 
> cc
> 
> Gonzalo Camarillo <[email-masked]>, Mary Barnes 
> <[email-masked]>, SIPPING LIST <[email-masked]>
> 
> Subject
> 
> WG review of draft-ietf-sipping-presence-scaling-requirements-01
> 
> 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.

Initially these requirements were part of the scaling analysis
document and we were asked to move them to a separate document.

I still prefer to have this document published as separate RFC
as I think it will be referred to from various optimization
suggestions drafts.

> 
> 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.
Done

> 
> - 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.
> 
Done

> - 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.

As many of the possible optimization solutions may affect privacy it
seems that we need these requirements to make sure that the solution
does not make privacy weaker.

> 
> - 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."
> 
Reworded

> - 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?" ;-)
Can not think of another wording.
Anyway, there are communities that have tens of millions or even more.
> 
> - 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?

Rephrased

> 
> - 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./
> 
Adopted

> - 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 ;-)
> 
These examples that you are giving actually say that most of the
time we do not think about actual deployments unless we have to.
Anyway, I have smoothed it a bit.

> - S4, page 5:
>   s/When servers is connecting to another server/When a server is
>   connection to another server/
> 
Fixed.

> - 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.

Meant more about SIP protocol that has several messages that would not
have been there if it was designed over TCP only.
Reworded.

> 
> - S4, page 5: please expand RLS on first use.
> 
Done

> - 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.
> 
Reworded

> Thanks,
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> Email: vkg@{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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 3 Jul 2008 19:36:00 +0300

Vijay,

New draft has beend published:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-presence-scaling-requirements-01.txt

Comments below.

--Avshalom

Done

Done

Reworded

Rephrased

Adopted

Fixed.

Done

Reworded