Subject: [Simple] Draft minutes: SIMPLE at IETF66

From: Robert Sparks <[email-masked]>
Date: Sat, 15 Jul 2006 19:26:38 -0400

Please reply with any edits/corrections/needed clarifications to  
these minutes ASAP.

Thanks,

RjS
----------

IETF66 - SIMPLE - Minutes
11Jul2006 - Tuesday Afternoon II

Summary:

- Report: Publication has been requested for patch-ops and
   presence-rules. Revised documents have been requested for
   prescaps-ext and the partial-* documents before requesting
   their publication.

- There was consensus in the room to abandon the effort to
   standardize composition at this time. We will verify that
   any dangling dependencies this creates in other SDOs can
   be rectified. We will capture what we do know about composition
   as part of the annotated overview work.

- There was consensus in the room to not pursue the presence
   policy capabilities work at this time.

- Aki's "chat" draft has been simplified based on feedback from
   IETF65. The list will be polled for whether to pick up work
   as described in the current document after this meeting.

- The IMDN draft is very close to last-callable. Please review
   it if you have not already done so.

- The room showed interest in refining the presence scaling
   and performance analysis document targeting an Informational RFC

- The remaining milestones in the proposed new charter text
   were reveiwed and several were deleted (based on the above
   decisions). The xcap-package milestone currently remains but
   may turn into a hand-off to SIPPING as part of the config-framework.

- Feedback is requested on draft-garcia-simple-presence-dictionary and
   draft-saintandre-xmpp-simple

----------------------------------------
RAW NOTES: DEAN WILLIS
----------------------------------------
SIMPLE Session 1 July 11,2006

Chairs: Robert Sparks, Hisham Khartabil
Recorded by: Dean Willis

Topic: Agenda and Status
by Chairs
Slides presented:
http://www3.ietf.org/proceedings/06jul/slides/simple-0.ppt

Agenda reviewed and accepted

Chairs request review of simple-chat and draft-garcia-simple-presence.

Topic: Presence Policy Capabilities
by Jonathan Rosenberg
Slides presented:
http://www3.ietf.org/proceedings/06jul/slides/simple-0.ppt

Documented reviewed by author using slides.

Noted by HGS: Overall SIMPLE system is far from simple. We should  
look at each
item, especially those for which we have no deployment experience,  
and ask if
the complexity added outweighs the benefits, or if there might be  
harm or the
encouragement of a non-compliant implementation on the server side.  The
proposed approach may be over this threshold.

Response: it is clear that some vendors  will want to do their own
authorization policies. This is however an interesting point for  
discussion.

Question: It seems that separation of the web app from the presence  
server
might be able to eliminate any special extension requirements, but  
that is
debatable. Noted that the common policy documents have some extension
capability, but it might not be implemented in a useful (or the right  
way).

Poll: Would you implement this? (only a few).

Noted: We need to come up with a common starting point here. If we  
don't, we'll
degenerate to the least common denominator of OMA or other profiles.

Noted: There's a lot of complexity in the user interface to deal with
variations in capabilities.

Noted: One point in this design was to eliminate dependence on  
specific vendor
implementations.  We need the ability to convey something that goes  
beyond the
base presence document that we have today.

Counterproposal: new presence rule sets could be put in separate  
namespaces

Poll by chairs: If you feel there is a compelling need to pursue and
standardize this mechanism now: Strongly opposed.

Possible problem: Do any other SDOs refer to this thing? We need to  
follow up
on list and via liaison to verify this.

Topic: Presence Processing Model and Composition
by Jonathan Rosenberg
Slides presented:
http://www3.ietf.org/proceedings/06jul/slides/simple-2.ppt

Problem statement reviewed.

Proposed that we don't really need this right now.

Comment: Two problems people report with SIMPLE are: 1) Too much  
bandwidth
consumed, 2) Don't know how to do composition.  But we don't really  
know what
we need to do about this yet.

Comment: Interoperability is an industrywide issue that has to be  
resolved
sometime.

Comment: OMA has gone ahead with a declaration that they need  normative
composition policy. We need some kind of statement about this.

Response: In the absence of use cases, how do they know they need it?

Comment: We already have an example here. We either really care which  
way the
composition works, in which case we should spec it, or not?

Response: I've always viewed that there should be a great deal of  
flexibility
in the way that composition might be done. Do we need a spec that  
says "This is
exactly how composition works" or should we wait and see a couple of  
working
approaches before we standardize it?

Comment: We've done too few "overview" documents that give people a  
clear sense
of how pieces fit together. This document has a lot of information  
that is
useful here. Perhaps we could mine stuff out of here and put it into the
architecture document. But we probably do NOT need an RFC that  
specifies a
fixed processing model.

Comment: this is the document beyond which people need to start  
thinking.

Chair comment: We will mine this thing for useful material but not  
pursue
normative descriptions from this document.

Report back: 3GPP references processing model and composition.

Topic: Composition
led by Henning Schulzrinne
Slides presented
http://www3.ietf.org/proceedings/06jul/slides/simple-3.ppt

Problem background reviewed.

Discussion: This is a good thing to figure out, but we don't have a  
current
need in the industry to do this. We should simply allow vendors to  
figure out
their own composition policies. Proposed that we put this aside along  
with the
presence processing model.

Noted that all the commercial things have very simple composition  
policies
today.

Conclusion: academic work may continue, but SIMPLE will not address.

Off-agenda process sidebar

Process commentary: We seem to be changing our model to "has market  
need" vs
"is interesting and useful". For example, do we want to delay work on  
SPIT
until somebody asks for it? Or are we just in a document-shooting mood?

AD response: Let's not go out of our way to find new work.

Comment: There are some things, like SPIT, where we want to plan  
ahead. Other
things we need to wait until we understand the problem before  
attacking it.

Topic: SIMPLE Advanced IM Requirements
Slides presented:
http://www3.ietf.org/proceedings/06jul/slides/simple-4.ppt
led by Markus Isomaki

Open question: Are there any things beyond the four ideas described  
in the
slides, that we want to work on?

Four open issues related to IMDN given, and one open issue on SIP  
MESSAGE
max-size.

Discussion on message size ensued. It may be easier to send a message  
in the
reverse direction saying "your message was too large" than to develop an
automable response.

Chair comment: This document is a scratchpad to help us keep from  
forgetting
stuff. We don't intend to publish it.

Question: Are there any other SDOs that we need to check with as we  
wrap up?

Noted that the work of niemi-simple-chat is still needed by OMA, even  
though
it's now in XCON.

Topic: IMDN
by Hisham Khartabil
Slides presented
http://www3.ietf.org/proceedings/06jul/slides/simple-5.ppt

Question: Are you describing exactly when one sends or does not send  
IMDN, or
is it left to server choice. (there's a SHOULD in the doc). Repsonse:  
it's
usage, not implementation. Requested that this be clarified as to its  
guidance.

Question: Should there be a message ID in the delivery report?  
Discussion
indicated that it should be included, because somebody might care.

Open Issue 1: use of "require" mechanism to require rejection of  
message if
IMDN not supported? Consensus to withdraw this requirement.

Open Issue 2:  Readdressing of requests in forwarding. Does this break
end-to-end encryption? Noted that if it were encrypted, the  
intermediary can
either read the message and pass it on, or not read it at all and cannot
process it. Of course, it could be signed, which would probably break  
and needs
list discussion.  This also needs careful security review.

Question: What is the expectation for notifications sent to a list?  
Do we get
an IMDN for each recipient, or just one for the aggregator? Response  
that
that's in the list aggregator stuff, and is outside the scope of this  
draft.

Topic: Interdomain Scaling Problem
by Avshalom Houri
Slides presented:
http://www3.ietf.org/proceedings/06jul/slides/simple-6.ppt

Question: Is this verbosity unavoidable? Also, are there other  
models, used by
other systems, that are substantially more efficient? For example, we  
have
subscription refresh traffic that others might not. Also, is it  
useful that we
have hundreds of watchees per user? So what are underlying casues versus
operational assumptions?

Comment: This is great work. We probably need to consider "how much  
better
could we do" as a next step. It should be possible to produce a best- 
case
model. This should account for things like shared views. We should  
keep working
on this, model the mechanisms, and move forward.

Comment: we need more analysis before requirements. That said, would  
like to
assure that we cover privacy and security explicitly in the work.

Question: do we have real numbers on watchers and watchees? There are  
probably
real world cases with lots. One such case (DoD) was pointed out.

Topic: Interdomain Practices
by Avshalom Houris
Slides presented:
http://www3.ietf.org/proceedings/06jul/slides/simple-7.ppt

Responses requested: Doe we need to publish this as a BCP? IS this  
the right
info? Anybody else want to contribute?

Comment: This seems to be worth doing. It would be good to get  
additional
operational experience.

Question: Do you issue this right away, or wait until there are specs  
to fold
in?

Topic: XMPP-SIMPLE Interworking
Review requested by chairs.

Topic: Rechartering
by chairs
slides presented

Comment: xcap and config are definitely swirled up. August is not  
achievable.
Also need to delete advanced messaging requirements and need to talk  
about
changing working groups on some drafts. Presence composition  
milestone can also
be deleted.

Comment: Can we possibly conclude on optimization and scalability  
issues by
July 2007? Does that work happen here or elsewhere? There may be  
items that
come out of the discussion with SPEERMINT that we need to account for  
in our
milestones.

Discussion of milestones continued.

There does seem to be interest in the optimization/scaling problem  
statement
draft.

Proposed: take the optimization document on with the intent to  
produce an
informational document.

Poll: If you think we should expend WG cycles refining the  
optimization problem
statement document into an informational RFC that would be refined by  
SIMPLE:
Noted mild positive response.

----------------------------------------
RAW NOTES: BRIAN STUCKER
----------------------------------------

SIMPLE

Agenda Bash

Intro/Administrivia/Agenda Bashing

     * Updates : getting closer to being done, lots in the RFC  
Editor's Queue.
     * Draft-niemi-simple-chat-05
           o All controversial issues removed
           o Adopt as a WG item?
           o Will be asking on the list if this is something to  
pursue as a group. People need to read it and get opinionated.
     * Draft-garcia-simple-presence-dictionary-00
           o Sigcomp dictionary for presence.
           o Needed by OMA
           o If interested in it, email [email-masked]

Policy caps

Johnathan Rosenberg

     * Problem Statement:
           o Possible variation across providers in sets of  
authorization policies that are available.
                 + Subsets of what is defined in presence-rules
                 + Provider-proprietary "macros" like "high privacy"  
and "low privacy"
           o Assumption that clients create authorization documents  
and upload them to the server.
           o So- how does client know what kind of authorization  
policies can be placed in its document?
     * Basic approach
           o Common Policy Capabilities
                 + Defines a policy capabilities document mirroring  
common policy.
                 + <conditions>, <actions>, <transformations> and  
<identity>, <sphere>, <validity>
           o Presence Policy Capabilites
                 + Declarations for support for each?
           o Do we need this?
                 + Not needed if
                       # Clients use web applications or any servier- 
side applications to generate authorization policies
                       # Clients are matched to a particular provider  
and are hard coded with their capabilities
                       # Client/Server interfaces remain proprietary  
for control of authorization policies
                 + (Discussion at Microphone)
                       # Henning Schulzrenne: Concern is that overall  
simple system is far from simple. We should look at any particular  
item and see that given we have no deployment experience, to see if  
thigns we add are adding complexity or harm versus help.
                             * Increases complexity.. now have to  
deal with combinations.
                             * Encourages non compliant  
implementations at the server.
                             * Both seem like things we don't want to  
do.
                             * When we did the implementation, the  
student working on it has not complained that any one of these tags  
is so much harder than others.
                             * At a loss as to if this is simply  
implementation laziness rather than policy.
                             * If we want to do policy then we should  
only do thigns we're worried about.
                       # Jonathan Rosenberg:
                             * There is an issue if there are totally  
proprietary extensions from the server.
                             * I want to get rid of this, I think  
they're more complicated than they are worth.
                             * It is fair to say that there are  
places that will want to do their own authentication policy.
                             * Counter-argument if you have a non  
compliant server, just match it with a non-compliant client.
                       # Hannes:
                             * Common policy framework.
                             * If the client uses web applications to  
do authorization then we don't need this.
                       # Jonathan Rosenberg: Not true. It's still  
needed.
                       # Hannes:
                             * If we extend existing documents with  
new capabilities, that doesn't mean that current documents are wrong.
                             * In common policy, it's not possible to  
omit certain tags.
                       # Jonathan Rosenberg: Poll of the room, raise  
your hand if you already have a SIMPLE implementation. (few hands)
                       # Eric:
                             * If we don't come up with a common  
starting point, then other standards orgs will.
                             * Doesn't matter if you're customizing  
with a service provide if you don't have a general framework.
                       # Jonathan Rosenberg: How does the client use  
the information it gets in XML for authorization, not clear.
                       # Henning:
                             * If I spend a lot of time trying to  
build a client that does common policy, and someone comes along and  
rips a bunch out of the XML, then I've wasted my time.
                             * Discourage random subset  
implementations (RFC minus tags I didn't like).
                             * Have the ability to convey something  
that goes beyond base documents, and then we can talk about the model  
we want.
                       # Jonathan Rosenberg:
                             * Counter-proposal: If you're not  
worried about implementing a subset, then put those elements in a  
separate namespace if it's supported.
                             * (Henning agrees)
                       # Robert Sparks (Chair)
                             * Hum vote:
                                   o If you feel there is a  
compelling need to pursue and standardize this right now, then hum:  
(Result: NO HUM)
                                   o If you believe that we should  
not take this on right now, then hum: (Result: LOUD HUM)
                       # Keith Drage:
                             * You can't take it off the charter,  
it's already on the charter.
                             * 3GPP at one point did refer to these  
items.
                       # Robert Sparks (Chair): We'll take it to the  
list to make sure no one is left in a lurch.

Presence-processing

     * Problem Statement
           o No agreement yet on
                 + How composition on privacy filterin relate
                 + Wht it means to do composition
                 + How to override presence data
                 + How to set various fields in a PUBLISH request
           o Solution:
                 + Define a presence server processing model
     * Basic Content
           o Client Processing
                 + Reporting
                 + Over-riding
           o Presence server processing
                 + Subscription processing
                 + Document processing
                       # Collection
                       # Composition
                       # Privacy filtering
                       # Watcher filtering
                       # Post-processing composition
           o (Do you combine tuples if they wind up looking the same  
after an operation is taken upon them, etc.)
     * Issues Yet to address
           o What is presence federation
           o Derivation of presence from non-presence sources
                 + Registration states
                 + Dialog states
           o How lying and polite blocking are modeled and controlled
           o Union compositor concept
           o Pres vs. SIP URI
           o Telephony features impacting presence states
     * Questions
           o Do we need this?
           o Is this higher or lower priority than other work?
           o Is there an implementation problem that's not covered yet?
           o There's problems that are more important, it's a  
theoretical problems.
                 + Markus: There's not enough understanding as to  
what needs to be done here. I don't think we should do this right now  
because we have no requirements.
                 + Avshalom Hauri:
                       # There is value in this as an informational  
item.
                 + Keith Drage:
                       # We need a statement around if things are  
being done wrong currently before we try to correct it.
                 + Jonathan Rosenberg:
                       # If OMA needs a statement on how this should  
work, then maybe they're too premature to spec it out as well.
                 + Paul Kyzviat:
                       # The composition policy that Henning was  
talking about is not consistent with the model (it's not per  
subscriber).
                       # Either this is useful now, or it's not  
useful because we have a real practical implementation.
                       # We can go either way, so we need to make  
some decisions about how we care about composition being done.
                 + Jonathan Rosenberg:
                       # Fallout is that you might want to specify a  
composition language.
                       # Do we need a spec to allow developers to  
build a compositor without having to think.
                 + Henning:
                       # Is the document something like that useful?
                       # Is it more useful to expand on some items on  
the previous slide?
                       # Are we oversubscribed?
                       # It's hard for new people to get a sense  
around how this all works, which makes this document useful as a good  
way to see how everything works. Informational, not normative.
                 + Robert Sparks (Chair): Are there elements that we  
can mine out of this that are useful.
                 + Henning:
                       # There are different points of the complexity  
spectrum that different people will implement, so there's no one way  
to do it. Don't try to be overly prescriptive.
                 + Jonathan Rosenberg:
                       # Once you bring it in, then it brings work.
                 + Henning:
                       # Don't do controversial bits, just do the  
parts that are already resolved.
                 + Jonathan Rosenberg:
                       # It's a fair bit of work.
                 + Hisham (at microphone):
                       # In my opinion this is a trial and error  
thing to do with code to figure out what we need. We need  
implementation experience to figure out what we need to focus upon.
                 + Jonathan Rosenberg:
                       # There are some market requirements behind  
this that I think are potentially valuable.
                 + Keith Drage:
                       # What we need is a document that says this is  
what you need to start thinking about, that they can't just go  
blindly implementing things.
                 + Jonathan Rosenberg:
                       # The market will weed out stupid  
implementations that have no value.
                 + Robert Sparks (Chair):
                       # Find the things that are useful (likely a  
small amount of text).
                       # If we find tidbits that are useful as a  
future warning, then put it into a draft.
                       # Don't have enough real-world experience to  
do protocol element work.
                       # The essence is that we're mine this thing  
for issues that we can use in a Hitchhiker's Guide type material to  
be captured.
                       # We're not going to let it all fall through  
the cracks so it actually guides the implementers away from land- 
mines we've already identified. When we know what our future issues  
are, update it then.
                 + Cullen Jennings:
                       # HHG is an annotated history of how we got here.
                 + Robert Sparks (Chair):
                       # We need something that ties everything  
together, but less than an architecture document.
                 + Andrew Allen
                       # 3GPP does refer to policy caps as a shell,  
they're only desirable and not critical path.

Composing Presence Information

     * Motivation for Composition
           o Different sources of information that need to be merged  
that's not just a union.
                 + Remove stale information
                 + Remove contradictory info
                 + Remove redundant info
                 + Generate new, inferred presence information
                 + Represent information in a useful way
     * Steps of Composition
           o Discarding stale and redundant info
           o Derivation of new presence info
           o Remove any conflicts
           o Merge tuples
     * Discarding
           o Clsoed contacts
           o Old contacts
           o Unreferenced
     * Deriving presence info
     * Provide additional information
           o Device may not support certain extension and so cannot  
publish that information
           o Users may not always express presence info manually, and  
there are many assocaitioans that can be auomatically made
           o Uasge examples: on the phone, driving, etc.
     * Derivation of presence
     * Static presence info
           o Example: my home pc is in a certain location - include  
location even though it isn't published by the PC
           o A rule can be defined for this:
                 + devideID =.. =>content
           o Alternatively, use a static presence document.
     * Conflict resolution
           o Allows the compositor to remove inaccurate info
           o Must first detect information conflict, then choose how  
to resolve it
           o Usage exmpales:
     * Detecting infor conflict
           o Some info conflict can be easily detect
                 + Place-is
                 + Privact
                 + Location ino
           o For other information, conflict is less clear
                 + Activitiy could be on-the-phone away and appointment
                 + Place-type could be outside and stadium
     * Big questions
           o User-specified rules or guidelines?
           o Per-presentity or per-watcher?
                 + For rule language, per presentity seems sufficient
                       # Establish "truth"
                 + More complicated tailoring probably reuires a  
programming language.
           o JR:
                 + I think this is a good thing.
           o Henning:
                 + For now, recommendation is to do union composition?
           o JR:
                 + No, vendors and providers will control composition  
logic. This is the current reality.
                 + Put this proposal aside along with presence  
processing.
           o Cullen Jennings:
                 + Compositors are pretty simple today.

SIMPLE Advanced IM Requirements (Markus Isomaki)

     * Background and Purpose
           o The current draft is a revision of draft-rosenberg-simle- 
messagnig-requirements-01
           o That draft drew requirements e.g. from draft-niemi- 
simple-im-iwreless-reqs-02, which tried to capture 3GPP/IMS related IM.
     * Scope of the requirements
           o IM disposition notifications
           o Is-composing
           o Conent capabilities
           o Page-mode groups
           o Multiparty MSRP related reqs (including "private"  
messaging, nicknames) currently missing.
           o Anything else SIMPLE should be working on related to IM?
     * Specific Open Issues Related to IMDN
           o IMDN and intermediaries
           o IMDN in session-mode messaging
           o REQ-DISNOT-11/12/13, REQ-COMP-14.
     * Open Issue related to SIP Message max-size indication
           o REQ-CONTENT-2: A 413 response MUST be capable of  
infication the max size.
           o (Microphone)
                 + Henning: In practice I think we'll get two values  
for this
                       # One is infinity.
                       # The other is a lower value.
                 + JR: SMS gateway
                 + Henning:
                       # Ok, agreed, SMS gateway is an example.
                       # We use a set mechanism that is not specific  
to message.
                 + Markus:
                       # I don't think that's apropos with this  
proposal, someone else can deal with that.
                 + JR:
                       # What would an automata do with this?
                       # Just send a message back in the opposite  
direction that says "Too big".
                       # (JR/Henning agree)
     * Next Steps
           o Are we conering all the areas we should work on relate  
to IM capabilities.
           o Should we specifically ask input from OMA?
           o Resolve the IMDN related open issues in order to get the  
draft on the correct track.
           o Resolve the SIP MESSAGE maximum size issue
           o (Microphone)
                 + Henning: I'm always for capturing requirements. Do  
we need an RFC or simply a WG consensus that we can use for a  
scratchpad.
                 + Robert Sparks (Chair): It's a scratch pad.
                 + Markus: Agree, scratchpad.
                 + Robert Sparks (Chair): Go read this, and get  
opinionated on what we really need to take on.
                 + Dean Willis: OMA wants SIMPLE chat.
                 + Robert Sparks(Chair): They want things that have  
moved to XCON.

IMDN (Hisham Khartabil/Eric Burger)

     * Changes
           o Combines two I-Ds.
           o IMDN- Instant Message Disposition Notification
           o Endpoints may send positive delivery notifications and  
should send negative delivery notifications if requested to.
           o (mic)
                 + Henning:
                       # Are you describing exactly when a server  
sends or not or is it implementation choice?
                       # Getting frustrated as if these SHOULDs are  
operational or design guidelines?
                 + Ben Campbell:
                       # I think it went to a  SHOULD was due to a  
lack of information, not optional implementation.
           o Status changed from sip style to strings "success"  
instead of "200".
           o Added really-from and really-to headers
                 + Really-from indicates previous hop (intermediary)  
in order to send the IMDN
                 + Really-from headers converted to Really-to headers  
in IMDNs.
                 + Aggregation text was added.
                       # People, please read it and give feedback.
           o Message-ID not mandated but needed if sender keeps state  
(sent items box)
                 + If you don't keep state for the message you've  
sent then there's no point in getting a notification because you  
don't care.
                 + IMDN is a message as well, so it needs Message-ID.
                 + (mic)
                       # Eric Burger:
                             * Also realize that message-id which  
comes from the email world is for a lot of debugging, etc.
                             * You may not care about message-id, but  
other intermediaries might.
                       # Ben Campbell:
                             * Message-ID is not there if IMDN is not  
requested.
                       # Hisham:
                             * Eric just convinced me message-id is  
needed in all messages and IMDNs when IMDNs are requested.
     * Open issues
           o Do we want to allow the sender to invoke the "required"  
mechanism to tell the recipient to please just reject the message if  
it does not support IMDN?
                 + Hisham votes no.
           o Rejecting the IM based on this will reveal such private  
information abut the recipient to the sender.
           o Opinions?
           o (mic)
                 + Ben Campbell:
                       # I agree no for complexity reasons, and we  
get little value.
                 + Eric Burger:
                       # We can silently ignore it, or we don't mean  
requires when someone says require?
                 + Ben Campbell:
                       # Don't address it.
                       # However, CPIM allows you to do it  
arbitrarily. Someone could construct it that way.  I don't think we  
should suggest it though.
                 + Eric/Hisham/Robert Sparks/Ben - It's out (agreed).
           o An intermediary that forwards an IM may change the  
recipient address in the CPIM to header field when forwarding (for  
example, aURI-List server change the recipient address from its own  
to the address of the final recipient of that message). In this case,  
the intermediary MUST add a CPIM original-to header to the CPIM message.
           o Is this a problem for end-to-end encryption? If so, how  
to go through GWs?
                 + Ben Campbell: It's not a problem.
                 + Miguel Garcia: Exploders already have the key, not  
a problem.
                 + Aki Neimi: It could be signed.
                 + Robert Sparks (Chair): Probably worth list  
discussion (around signing). Take it to the list. This is going to  
WGLC soon.
           o Hisham: I think these are solvable in the next couple of  
weeks so the charter is achievable.

SIMPLE Problem Statement (Avshalom Houri)

     * Deployment experience of SIMPLE based systems shows  
scalability issues with respect to number of messages
     * Number of messages in several typical deployments
     * Two categories of optimizations were considered:
           o Dialog saving optimizations: event-list or uri-list that  
collapse number of subscriptions
           o Notification optimizations: subnot-etags by Aki Miemi  
which suppresses non necessary notifies.
     * Computation
           o Described in detail in the draft
           o Input parameters
                 + Subscription lifetime
                 + Presence state change/hour
                 + Subscription refresh interval/hour
                 + Total federated presentities per watcher
                 + Number of dialogs per watcher (optimization  
dependent)
                 + Number of watchers in each domain.
     * Widely distributed inter-domain mode.
           o Users of each domain are not usually subscribed to  
presence within the domain
           o For example small public servers
           o Numbers used
           o Subscription lifetime : 8 hours
           o Presence state changes per hour : 3
           o Subscription is refreshed every hour
           o Total watched presentities : 20
           o Number of watchers in each domain -20k
           o Number of dialogs per watcher : 20 (non-optimized), 1  
(optimized)
           o Not optimized: 70.4M messages per hour, 2444/sec.
           o Optimized: 39.36M message per hour, 1300/sec.
     * Other models
           o Simple case : t wo domains connecting
           o Associated inter-domain : enterprise servers. Assuming  
it is the same as widely distributed inter-domain with respect to  
traffic between domains
           o Very large network peering : e.e. consumer IM networks.
           o Intra domain peering
     * Summary
           o The numbers presented are only between two domains, when  
more domains are connected the number of messages will be multiplied
           o Although current optimizations can reduce the traffic by  
up to 50%, the traffic is still very high
           o Conservative numbers were used, in real life numbers may  
be even higher.
     * Conclusions
           o Further work I SIMPLE WG is needed in order to have  
beeter optimizations
           o Initial set of requirement is included in the draft.
                 + Linear scaling
                 + Minimal state
                 + Must be able to scale to millions of concurrent users
                 + MUST support a very high level of watcher/ 
presentity intersections in various intersection models
           o (mic)
                 + Henning: I don't think inter-domain is important.
                 + Avshalom: You could do more optimizations in intra- 
domain.
                 + Henning:
                       # Is this unavoidable?
                       # Are there other models other systems do that  
are more efficient? Others have hard state models, for instance.
                       # Is the user model that we're going to have  
going to be linear and useful? :  I think it does not.
                       # Most information is not very interesting in  
the notifications.
                 + JR:
                       # I like the work and thank you for  
quantifying it.
                       # Next step is to figure out how much better  
can we do than what we're doing today.
                       # What is the best that is possible to do and  
how close do we get?
                       # Shared information has the potential to  
reduce the amount of messaging.
                       # Presence systems remain stubbornly  
proprietary. SIMPLE is good for inter-connect.
                       # We should continue working on this.
                 + Ben Campbell:
                       # May need more analysis before talking about  
requirements.
                       # Need to cover security and privacy.
                 + Aki Neimi:
                       # Should continue.
                 + Miguel Garcia:
                       # Presence dictionary should be part of the  
discussion.
                 + Dean Willis:
                       # DoD has requirements for thousands of watchers.
     * Purpose of this Draft
           o Provide a catalog of high-level BCPs derived from  
experience in operating large enterprise and consumer IM communities
           o Two categories of recommendations in this draft.
                 + A recommended minimum profile for SIMPLE  
implementations to satisfy expectations of "real world" users.
                 + Techniques that can assist in scalability.
     * Next Steps
           o Does the WG see utility in documenting this kind of  
information?
           o Is this the right information to cover?
           o Are there others with operational experience to contribute?
           o (mic)
                 + Jon Peterson (as participant);
                       # I think this is good, we need more people  
with operational experience.
                 + JR:
                       # I think it's interesting to do.
                       # Is this the end document or start document?
                 + Avshalom:
                       # I'm not sure myself.

Robert Sparks (Chair) : Go take a look at draft XMPP/SIMPLE draft,  
and give Peter comments.

Rechartering (Robert Sparks, as Chair)

     * If you don't like the rechartering steps, comment on the list  
soon.
     * Submission of mechanism for presence composition, messaging  
requirements goes away from today's conversation.
     * Dates need to be real.
           o (mic)
           o JR:
                 + XCAP event package Config package draft is swirled  
up. Package and format packages are likely to be put together and  
punted over to SIPPING.
           o Robert Sparks:
                 + So this could go either way, and not August.
           o JR:
                 + Yes.
           o Robert Sparks (Chair):
                 + XCAP milestone dates will change or it needs to  
change working groups. Needs discussion.
                 + Anything from the advanced messaging reuirements  
scratchpad will discover stuff to be finished by this year. We don't  
know what those are yet, when we do we'll replace it.
           o Ben Campbell:
                 + Will optimizations/scalability delay finishing up  
the work group?
           o Jon Peterson (as Area Director):
                 + There's some discussion in Speermint that will  
cover Avshalom potentially.
                 + AD's want Speermint to be a tactical WG and not  
pollute it, so we don't want to move things wholesale.
                 + Recommendation would be to continue to investigate  
work here.
           o Ben Campbell:
                 + First draft is not just domain naming.
           o Jon Peterson:
                 + Speermint as it is currently cast is not centered  
on SIP or SIMPLE, but on conventions in the interdomain context.  
Protocol work gets pushed off to the appropriate WG (e.g. here).
           o Avshalom:
                 + Problem statement is not currently a milestone?
           o Robert Sparks (as Chair):
                 + Not at the moment, but it can go through the  
review process.
           o Jon Peterson (as AD):
                 + No need to be fussy, if there's a strong feeling  
in the room we can add it now on a hum.
           o Robert Sparks (as Chair):
                 + Room seems interested.
           o Ben Campbell:
                 + Add milestones as we come up with them seems  
appropriate.
           o JR:
                 + I think problem statement has persistent value  
long after you are done. BCP seems fuzzy though.
                 + Propose: take on problem statement for information  
document.
           o Jon Peterson (as AD):
                 + Speermint is a good place for it, and given that  
we don't have it there now, it's ok to have it here.
           o Robert Sparks (as Chair):
                 + If you think that we should expend working group  
cycles refining the problem statement document into an informational  
document (HUM): Hum vote is yes.
                 + (Meeting Close)

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple