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 miguel.an.garcia@nokia.com 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. + , , and , , 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)