[Sipping] FW: FW:WGLC Review: draft-ietf-sipping-presence-scaling-requirements-01.txt

["Jean-Francois Mule" <[e-mail]>]

Avshalom,

  Thanks for the repetitive pings and sorry for the delay in my response re: draft-ietf-sipping-presence-scaling-requirements-02.txt

Here is some feedback based on a quick read of draft-02:
 - The new draft does address a few comments and it looks better.
 - I'm afraid there are now too much details in 2.1 and 2.2.1. for me and given the goal of this document.  This is also true for 4.1 on Very optimized SIP.
Per my comments, I would looking for a higher level summary (one to two concise paragraphs) providing the main learning or key take-away messages from all those numbers.  To me, that should belong to the intro of this requirement document. 
 - few typos " of by teds", " design phase; Trying"
 - use session peering as opposed to network peering which means L3 traffic exchange and IP packet peering to most people
 - a few language issues like:
Change
o REQ-008: The solution SHOULD NOT require significantly more state	
	in order to implement the solution.		then solutions based on current protocol in order to implement the	
			optimizations.
With something like:
o REQ-008: The solution SHOULD NOT require a significant increase in the amount of states to maintain compared to the current state management required by SIMPLEs.

 - the comment on REQ#11 was not addressed and I still find it hard to understand what this actually means

Best wishes to all for the year-end celebrations,
Jean-François.


> 
> ----- Forwarded by Avshalom Houri/Haifa/IBM on 12/11/2008 13:01 ---
> --
> Avshalom Houri/Haifa/IBM
> 02/11/2008 12:27
> To
> "Jean-Francois Mule" <[e-mail]>
> cc
> Gonzalo Camarillo <[e-mail]>, Mary Barnes
> <[e-mail]>
> Subject
> Re: [Sipping]        FW:WGLC        Review:        draft-ietf-
> sipping-presence-scaling-requirements-01.txtLink
> 
> 
> 
> 
> 
> 
> Jean-Francois,
> 
> Many thanks for your most detailed review. I have submitted version
> 2 that I hope answers most of your comments.
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-presence-
> scaling-requirements-02.txt
> 
> Regarding requirements 4, 5 and 6. I preferred to leave the
>  negative version of the requirements rather then using the
> positive version which is lengthier and may not cover all cases.
> 
> --Avshalom
> 
> 
> 
> 
> "Jean-Francois Mule" <[e-mail]>
> Sent by: [e-mail]
> 10/10/2008 12:22
> To
> <[e-mail]>
> cc
> [e-mail], Mary Barnes <[e-mail]>, Gonzalo
> Camarillo <[e-mail]>
> Subject
> Re: [Sipping]        FW:WGLC        Review:        draft-ietf-
> sipping-presence-scaling-requirements-01.txt
> 
> 
> 
> 
> 
> 
> 
> Hi,
> 
> On Friday, September 19, 2008 3:26 AM, Gonzalo wrote:
> > the authors are already working on the comments received from
> Vijay
> > and
> > Hisham. In any case, per my email below, we would like to get an
> > additional reviewer for this draft. Any volunteers?
> 
>   Find below a review of
>   draft-ietf-sipping-presence-scaling-requirements-01.
> 
>   The companion scaling analysis document is very informative and
>   captures many things that folks see as scaling issues.  As I
> wrote
>   below, it may be good to just outline these issues or
> shortcomings
>   clearly in the introduction.
> 
>   It is difficult to write requirement documents and what I've
>   focused on during my review is whether a solution designer can go
>   back to the document and say: have I met this? what does this
> mean
>   for my solution?
> 
>   Disclaimer: I've not followed the list with details on this and
> I'm
>   not building or working with users/operators of such large
> systems.
>   If some of these comments have been discussed on the list or are
>   off-track, fine with me, just ignore.
> 
> Jean-Francois.
> [e-mail]
> 
> --- page 3, Intro
>  | These optimizations should reduce the traffic in
>  | interdomain presence subscriptions.  The requirements
>  | are based on a separate scaling analysis document
>  | [I-D.ietf-simple-interdomain-scaling-analysis].
> 
> This text begs the question of what "traffic" reduction is this
> about?
> reduce the amount/size of traffic as in bandwidth?  or the amount
> of
> messages? the amount of small message? what about memory footprint
> and
> the CPU load as this was a goal of the quoted analysis document?
> 
> It would be good to have a more precise introduction.  Based on the
> content, and the scaling analysis, something like this would seem
> to
> fit:
>                 - the requirements described in this document
> should lead to
>                   protocol optimizations that reduce the amount of
> bandwidth
>          exchanged between presence systems, both in terms of the
>          number of the messages and their sizes (bytes on the
> wire).
>          It is also a goal that the management of steady states by
>          presence servers implementing these optimizations should
> be
>          significantly improved.
> 
> 
> It would be good to also have more information in the introduction
> on
> the scaling analysis, and one or two examples.  For example:
>   "based on a scaling analysis of the ... of presence systems,
> especially for the amount of messages required during busy hours of
> presence systems of ... users, the following has been document:
>                 o the bandwidth required to update ... can reach x
> GB.
>                 o the amount requests per second typically reach
> ...
>                 o steady states...
> 
> 
> --- page 3, "Suggested" requirements
> I'd remove "suggested" in the title: when this document becomes
> RFC,
> those are no longer suggested I think.  May be "proposed"?
> Also, the next sentence implies an "initial" set of requirements:
> if
> this document is ready for publication, this is the set for now so
> I
> would again make it more assertive:
>   This section lists requirements for a solution that will optimize
>   the interdomain presence traffic.
> 
> --- page 3, section 3.1
> | o  REQ-001: The solution SHOULD NOT hinder the ability of
> existing
> |    SIMPLE clients and/or servers from peering with a domain or
> |    client implementing the solution.  No changes may be required
> of
> |    existing servers to interoperate.
> 
>   I read this as: if a new solution is defined that optimizes
> things,
>   the SIMPLE entities supporting this new solution SHOULD also
>   interoperate with existing versions of the SIMPLE/SIP
>   implementations.
>   So, in a way, are you saying?
>                 - the solution should not deprecate existing
> protocol
>                   mechanisms defined in SIMPLE
>                 - the solution should define new extension
> mechanisms that
>                   would allow SIMPLE entities to improve
> performance
>   It may be worthwhile spelling this out more clearly so that folks
>   designing the solution can go back and say without a doubt
> whether
>   they met the requirement.
> 
> 
> --- page 3, section 3.2
>   o  REQ-004: The solution SHOULD NOT limit the ability for
>      presentities to present different views of presence to
> different
>      watchers.
>   o  REQ-005: The solution SHOULD NOT restrict the ability of a
>      presentity to obtain its list of watchers.
>   o  REQ-006: The solution MUST NOT create any new or make worse
> any
>      existing privacy holes.
> 
> These 3 requirements could benefit from being turn into positive
> requirements with more precision.
> 
> REQ-004: I'm not quite sure what you are driving to:
> Is it that
>  - the solution should continue to allow presentities to provide
>    different views of presence to different watchers
>    (I thought this was covered in the backward compatibility
>     requirement), or,
>  - the new solution must provide an enhanced mechanism for view
>    sharing but that this new mechanism must still allow different
>    views for different watchers?
> 
> REQ-005 has the same ambiguity: either it is covered by the
> backward
> compatibility case (and you can put this sentence as an example
> under
> REQ-001 I think, or you mean something like this:
>  - The solution must allow a presentity to obtain its list of
> watchers
> 
> I guess what I'm confused about is to see where are the new
> requirements you're imposing on the solution vs. keep what is
> already
> possible in simple.
> 
> 
> --- page 4
> REQ-006: this is vague.
> Are there any high-level requirements that you could derive from
> the
> view sharing draft and its ACLs that would give solution designed
> more
> information on what security properties to preserve?
> If the presence data model is changed, any pointer to another
> document
> that contains some privacy or security considerations?
> ==> I think the goal of such a requirement is to list a bunch of
> things that the solution designer checks afterwards.
> 
> 
> --- page 4, section 3.3
> | o  REQ-008: The solution SHOULD NOT require significantly more
> |    state in order to implement the solution.
> The sentence needs to say "more state than ___" and you should
> consider removing "in order to implement the solution".
> 
> | o  REQ-009: It MUST be able to scale to tens of millions of
> |    concurrent users in each domain and in each peer domain.
> "It" points to systems here I think when the previous sentences are
> using "the solution". Consider wordsmithing: "The solution MUST
> allow
> presence systems to scale..."
> 
> REQ-011: consider rewording to:
>   o  REQ-011: Protocol changes MUST NOT prohibit optimizations in
>      deployment models where there is a high level of cross
>      subscriptions between the domains.
> 
> --- page 4, section 3.4
> | o  REQ-013: The solution SHOULD allow for arbitrary federation
> |    topologies including direct peering and intermediary routing.
> 
> s/direct peering and intermediary routing/ direct and indirect
> peering
> per speermint terminology, I believe you mean "intermediary
> routing"
> as having a SIP service provider through which messages would
> transit
> between two peers.
> 
> 
> --- page 4, section 4
> This whole section would benefit from a first paragraph
> highlighting
> the areas to consider for optimization.  You have a succession of
> paragraphs that cover various dimensions (taking scaling
> requirements
> into consideration, server-to-server vs. client-to-server protocol
> requiremetns, transport protocol considerations and TCP-only use,
> etc.
> One or two sentences introducing the various dimensions to look at
> would be helpful.
> 
> --- page 5, paragraph 1
> nit picking the sentence that starts with however, consider
> changing
> to:
> However, it is apparent that additional protocol optimizations are
> possible and further work is needed in the IETF in order to provide
> better scalability of large presence systems.
> 
> 
> --- page 5, paragraph 2
> I think most of this paragraph must be deleted from the RFC-to-be.
> This is ok in a draft and has been well taken in sipping, but this
> has
> got to go:
>  "The IETF sometimes does not give the right priority
>   to actual deployments when designing a protocol but in this case
> it
>   seems that if we do not think about scalability with the protocol
>   design it will be very hard to scale."
> Check:
> http://www.ietf.org/internet-drafts/draft-iab-protocol-success-
> 04.txt
> 
> --- page 5, other paragraphs
> There are various nits that should be fixed; including a few here
> but
> this is not exhaustive:
> 
> s/(e.g. do not use unreliable protocol as UDP but only TCP)/(for
> example, do not use unreliable protocol like UDP but rely on TCP)
> 
> 
> s/When a server is connecting to another server using current
> protocol,/When a presence server connects to another server using
> the
> current SIP/SIMPLE protocol [xxx]
> 
> s/Another issue that is more concerning protocol design is/Another
> issue related to protool design is/
> 
> s/notifies/notifications
> 
> 
> 
> --- page 5
> Is it necessary to reference individual drafts like
> I-D.houri-simple-interdomain-scaling-optimizations when the authors
> list has intersections?
> It might be prefereable to summarize the key points in one
> paragraph
> and not carry this I-D dependency.
> 
> 
> --- IANA
> see http://tools.ietf.org/html/rfc5226#section-6.1
> 
> --- check Idnits prior to submitting next rev
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP