Scaling Requirements for Presence in SIP/SIMPLE
draft-ietf-sipcore-presence-scaling-requirements-02
Discuss
Yes
(Robert Sparks)
No Objection
(Cullen Jennings)
(Jari Arkko)
(Magnus Westerlund)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Adrian Farrel Former IESG member
(was No Objection)
Discuss
Discuss
[Treat as non-blocking comment]
(2009-09-24)
Unknown
I have entered a Discuss to hold the document pending the Discussion of draft-ietf-simple-interdomain-scaling-analysis with respect to the impact of Security on scaling (see also my Comment on this document). It is possible that the resolution of that other Discuss will lead to no changes being necessary to this document, but we have to wait and see.
Robert Sparks Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2009-09-24)
Unknown
1.
REQ-009: Presence systems (intra- or inter-domain) SHOULD scale in
linear proportion to the number of watchers and presentities in
the system.
To what does 'in linear proportion' refer to? I suspect it is related to the number of messages, state size, and management and processing load - it would be good to make this explicit.
2. It would have been useful to discuss and add a requirement about the scalability of the management applications and operational tools. As presence systems increase in number and complexity they still need to remain manageable and operational - this aspect is not discussed at all in the document.
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2009-09-23)
Unknown
Editorial comments/clarifications.
Abstract and first para of intro:
Abstract
The document lists requirements for optimizations of SIP/SIMPLE
that will allow for greater scalability of presence by reducing
the load on the network and the
presence servers due to inter-domain presence subscriptions.
If the WG is comfortable with SHOULD in these three requirements, then OK but I'm a little surprised these aren't MUST.
o REQ-001: The solution SHOULD NOT deprecate existing protocol
mechanisms defined in SIP/SIMPLE.
o REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate
with clients and servers that implement new presence scaling
features.
o REQ-003: The solution SHOULD NOT constrain any existing RFC
functional requirements for presence.
Slight re-wording for precision?
o REQ-011: The solution MUST allow presence systems to accommodate
on the order of ten of million users in each peer domain.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2009-09-24)
Unknown
The Gen-ART Review by Christian Vogt on 22-Sep-2009 raised a few
points:
- It would be worth mentioning in the introduction of the document
what the expected result of this document should be. Obviously,
we are expecting (or hoping for) an improvement in the scalability
of SIP/SIMPLE, but this should be made explicit. Also, do we have
estimates of how much SIP/SIMPLE will improve?
- The document only talks about "optimizations" to which the defined
requirement should apply. How about other types of protocol
enhancements, such as functional extensions? Wouldn't the defined
requirements apply to those just as well?
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown