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

[Avshalom Houri <AVSHALOM at il.ibm.com>]

Vijay,

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

Sorry for the late response.

--Avshalom




"Vijay K. Gurbani" <vkg at alcatel-lucent.com>
wrote on 16/04/2008 01:42:09:

> "Vijay K. Gurbani" <vkg at alcatel-lucent.com> 
> 16/04/2008 01:42
> 
> To
> 
> Avshalom Houri/Haifa/IBM at IBMIL, Sriram.Parameswar at microsoft.com, 
> aoki at aol.net, vs2140 at cs.columbia.edu, hgs+ecrit at cs.columbia.edu
> 
> cc
> 
> Gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>, Mary Barnes
> <mary.barnes at nortel.com>, SIPPING LIST <sipping at ietf.org>
> 
> 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 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