From stpeter@stpeter.im Tue Oct 6 09:02:25 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755763A68DA for ; Tue, 6 Oct 2009 09:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGKMVteUUSn3 for ; Tue, 6 Oct 2009 09:02:24 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id F3F6A3A68FC for ; Tue, 6 Oct 2009 09:02:23 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E4B240D35 for ; Tue, 6 Oct 2009 10:04:00 -0600 (MDT) Message-ID: <4ACB6A6F.9030200@stpeter.im> Date: Tue, 06 Oct 2009 10:03:59 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "speermint@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Speermint] requirements for presence and IM peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 16:02:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Section 4 of draft-ietf-speermint-requirements contains requirements for peering of presence and instant messaging in SIP-based systems. Here is some feedback regarding those requirements. In general, I am concerned about the use of the capitalized keyword MUST in these requirements, because it could be taken to override local policies or user-level privacy settings. For example, if we say that an entity absolutely MUST be allowed to subscribe to the presence of users in another SSP then operators might take that as saying that a user or a service-wide admin cannot block an entity from another SSP (or all entities from another SSP) from subscribing to the user's presence. I don't think this is what we mean here, but we need to make that clear. Some specific comments follow. Requirement #10 The mechanisms recommended for the exchange of presence information between SSPs MUST allow a user of one SSP's presence community to subscribe presentities served by another SSP via its local community, including subscriptions to a single presentity, a personal, public or ad-hoc group list of presentities. The phrase "to subscribe presentities" is missing some words. I think "to subscribe to presentities" is meant. However, I think it is better to say "to send a presence subscription request to presentities" because presumably the presentity needs to control who can and cannot see its presence information via some explicit approval mechanism. Requirement #11 The mechanisms recommended for Instant Messaging message exchanges between SSPs MUST allow a user of one SSP's community to communicate with users of the other SSP community via their local community using various methods. Such methods include sending a one-time IM message, initiating a SIP session for transporting sessions of messages, participating in n-way chats using chat rooms with users from the peer SSPs, sending a file or sharing a document. Use cases such as sending a file and sharing a document are not IM use cases. Furthermore, the text seems to imply that an SSP cannot exercise any granular control over which of the "various methods" are allowed. In my experience, an SSP might allow IMs but not groupchats, textual communication (IM and groupchat) but not sending files, etc. Requirement #12 In order to enable sending less notifications between communities, there should be a mechanism that will enable sharing privacy information of users between the communities. This will enable sending a single notification per presentity that will be sent to the appropriate watchers on the other community according to the presentity's privacy information. The privacy sharing mechanism must be done in a way that will enable getting the consent of the user whose privacy will be sent to the other community prior to sending the privacy information. if user consent is not give, it should not be possible to this optimization. In addition to getting the consent of users regarding privacy sharing, the privacy data must be sent only via secure channels between communities. Usage: "less ... notifications" ==> "fewer ... notifications". Typos: "if user consent is not give, it should not be possible to this optimization." ==> "If user consent is not given, it should not be possible to use this optimization." The phrase "secure channels" is not defined. Does this mean SIP signalling over TLS-encrypted TCP? It would be good to specify what's meant, or to point to the security considerations. Requirement #13 It should be possible to send a presence document with a list of watchers on the other community that should receive the presence document notification. This will enable sending less presence document notifications between the communities while avoiding the need to share privacy information of presentities from one community to the other. Usage: "less ... notifications" ==> "fewer ... notifications". This requirement says nothing about security. Presumably, information about the recipients of a given notification might also be private and therefore worthy of protection, just as under Requirement #12. Requirement #14 Early deployments of SIP based presence and IM gateways are done in front of legacy proprietary systems that use different names for different properties that exist in PIDF. For example "Do Not Disturb" may be translated to "Busy" in another system. In order to make sure that the meaning of the status is preserved, there is a need that either each system will translate its internal statuses to standard PIDF based statuses of a translation table of proprietary statuses to standard based PIDF statuses will be provided from one system to the other. Usage: In "different names for different properties" I would change the second instance of "different" to "various". The final sentence is a bit confusing and its directive to SSPs is not clear, even if we correct "of" to "or" in the middle. I might reword it as follows: To make sure that the meaning of the status is preserved, an SSP should translate its internal statuses to standard PIDF statuses. I don't think we want to recommend that SSPs exchange translation tables, because the maintenance issues are significant and there is no need to do this given that we have PIDF. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrLam8ACgkQNL8k5A2w/vz+mwCg3k58ehq3IOmho/y3Jnplcrrj IHkAn2s2RMJ63746RtLjfd3/LF6qq9el =ksSN -----END PGP SIGNATURE----- From dromasca@avaya.com Thu Oct 8 02:57:35 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA1928C128 for ; Thu, 8 Oct 2009 02:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGhW+ShMGakl for ; Thu, 8 Oct 2009 02:57:34 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E17283A67D7 for ; Thu, 8 Oct 2009 02:57:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,524,1249272000"; d="scan'208";a="186264550" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Oct 2009 05:59:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Oct 2009 05:59:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2009 11:58:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operations Directorate Review thread-index: AcpGsaA78HcQGvJqQpyxwnk68iNGswBS82VA From: "Romascanu, Dan (Dan)" To: , Cc: speermint@ietf.org Subject: [Speermint] FW: Operations Directorate Review X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 09:57:35 -0000 =20 -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Tuesday, October 06, 2009 8:20 PM To: Romascanu, Dan (Dan) Cc: Tina TSOU; Ron Bonica Subject: Re: Operations Directorate Review I reviewed draft-ietf-speermint-voip-consolidated-usecases-14 general remark: The draft very carefully limits its scope to voice on IP ("VoIP"). The author's first question was how that related to presence and instant messaging. My first question is how that relates to video, which in some systems (Skype, iChat, Marratech, and others) is used in parallel with voice. IMHO, the work is not done unless it also applies to video - and I suspect the use cases are all the same. general remark: the motivation behind the document is probably very clear to those who are writing it. RFCs are archival, meaning that someone is likely to come back 1000 years from now and try to figure out why it was written. That's not clear to me now, and will be absolutely unclear to that future historian. surprise: section 5.6 is surprisingly lean as compared to the various static use cases. That may be because it is hard to describe in general terms, but I was expecting a lot more detail there. On Oct 2, 2009, at 4:51 AM, Romascanu, Dan (Dan) wrote: > Hi Fred, > > This document is on the agenda of the 10/8 IESG telechat. Please send=20 > your review as soon as possible and no later than 10/7 COB. > > Thanks and Regards, > > Dan > > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Tuesday, June 30, 2009 4:54 AM > To: fred@cisco.com > Cc: Ron Bonica; Romascanu, Dan (Dan) > Subject: Operations Directorate Review > > Hello Fred, > As a member of the Operations Directorate you are being asked to=20 > review the following IESG work item for it's operational impact. > > IETF Last Call: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolid > ated-usecases-12.txt > > Please provide comments and review to the Ops-dir mailing list > (ops-dir@ietf.org) within the next two weeks, and include the authors=20 > of the draft as well. > > Thank you, > Tina > http://tinatsou.weebly.com/contact.html From jf.mule@cablelabs.com Mon Oct 26 04:10:51 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76943A68FB for ; Mon, 26 Oct 2009 04:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkveooZ+dzgS for ; Mon, 26 Oct 2009 04:10:50 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 3BFD83A681A for ; Mon, 26 Oct 2009 04:10:50 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n9QBAr7E004841; Mon, 26 Oct 2009 05:10:53 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 26 Oct 2009 05:10:53 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 05:10:36 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF1E1@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF1E0@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS-DIR review from Bernard Aboba on draft-ietf-speermint-requirements-08 Thread-Index: AcpWJP68gHGJeBlYSDCBvT1HIH7zGwAAAVaw References: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF1E0@srvxchg3.cablelabs.com> From: "Jean-Francois Mule" To: "Bernard Aboba" X-Approved: ondar Cc: speermint@ietf.org Subject: Re: [Speermint] OPS-DIR review from Bernard Aboba on draft-ietf-speermint-requirements-08 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 11:10:51 -0000 First, thank you Bernard for the OPS-DIR review on this draft from speermint. I apologize for the delay in my response to you.=20 You had provided these comments before the last IETF and I waited for the IESG reviews that came in 2 weeks ago to address them. =20 I will be submitting draft-08 which does address your comments (at least most of them). =20 I may release another update after the IETF in Hiroshima based on the feedback I receive, especially to add more background on some of the requirements (and to fully address some of your notes). Details inline below. Thank you, Jean-Francois jfm@cablelabs.com --- On Tue Jun 30 09:38:23 PDT 2009, Bernard Aboba bernard_aboba at hotmail.com wrote: > Review Summary: > Intended status: Informational >=20 > This document discusses requirements for session peering in voice, > presence, instant messaging and multimedia. >=20 > 1. Is the document readable? >=20 > In general, the document provides a readable listing of > requirements. However additional background on the requirements > could have been provided, which would make the document easier to > understand. Yes. I've updated the introduction to point to the reader to background documents: "A number of documents have been developed to provide additional background information about SIP session peering. It is expected that the reader is familiar with the reference architecture described in and use cases which describe how session peering has been or could be deployed for voice () and instant messaging and presence=20 ()." I understand your comment to also mean that some background is lacking on specific requirements. I've updated a few, and plan to do more editing in the next revision based on WG feedback. > 2. Does it contain nits? >=20 > Yes. See below. Fixed these and a few others, thank you for catching those. > 3. Is the document class appropriate? >=20 > Yes. >=20 > 4. Does the document consider existing solutions? >=20 > This is a requirements document, so it largely focuses on > requirements rather than solutions. >=20 > However, there are instances where the document does not > sufficiently discuss existing practices. The exciting DNS practices for *SIP traffic exchanges* as discussed inside the Speermint WG have been captured to the best of my knowledge. When we started this work, it was not uncommon to find IP addresses in SIP URIs (and some still do). Sections like 3.3.1. reinforce the use of DNS. > For example, in Section 3.2 the document refers to limitations of > DNS in providing different responses based on the querier: >=20 > "However, this DNS-based solution may be limited > in cases where the DNS response varies based on who sends the > query (peer-dependent SBEs, see below).... >=20 > Notes on solution space: > For advertising peer-dependent SBEs (peer variability), the > solution space based on [RFC3263] is under specified and there are > no know best current practices. Is DNS the right place for > putting data that varies based on who asks?" >=20 > Content Distribution Networks (CDNs) have quite a bit of > operational experience with use of DNS to provide > "data that varies based on who asks". Information on existing > approaches is provided in RFCs 3466, 3568, > and 3570. CDNs also have experience in use of application re-direct > for global load balancing. I was > therefore somewhat surprised that this document did not discuss or > reference work on CDNs. >=20 > While the document focuses on layer 5 peering, it does seem like it > would be worthwhile to at least have > some discussion of lower layer load balancing techniques such as > anycast (e.g. RFC 4786), which when > combined with DNS can be used to provide "data that varies based on > who asks". Your comment below points are insightful and they point to one aspect of this draft, the use of RFC3263 and DNS to locate the SIP signaling entities of your peers and how peers can give different entry points using DNS. I've read the references and see the benefits of pointing out those in the notes about the solution space. I made a few edits to capture them in draft-08. In particular, the new text for req#4 says: o Requirement #4: The mechanisms recommended for the declaration or advertisement of SBE and DBE entities MUST allow for peer variability. Notes on solution space: A simple solution is to advertise SBE entities using DNS and [RFC3263] by providing different DNS names to different peers. This approach has some practical limitations because the SIP URIs containing the DNS names used to resolve the SBEs may be propagated by users, for example in the form of sip:user@domain. It is impractical to ask users to use different target URIs based upon their SIP service provider's desire to receive incoming session signaling at different ingress SBEs based upon the originator. The solution described in [RFC3263] and based on DNS to advertise SBEs is therefore under-specified for this requirement. Other DNS mechanisms have been used extensively in other areas of the Internet, in particular in Content Distribution Internetworking to make the DNS responses vary based on the originator of the DNS query (see [RFC3466], [RFC3568] and [RFC3570]). The applicability of such solutions needs for session peering needs further analysis. Finally, other techniques such as Anycast services ([RFC4786]) may be employed at lower layers than Layer 5 to provide a solution to this requirement. For example, anycast nodes could be defined by SIP service providers to expose a common address for SBEs into DNS, allowing the resolution of the anycast node address to the appropriate peer-dependent service address based on the routing topology or other criteria gathered from the combined use of anycast and DNS techniques. Let me know if this is a first step to address your comment. I am not sure about putting more details on the solutions used in CDN networks in this document given the document's intent to catalog the solution space along with requirements. I welcome more feedback. > 5. Does the solution break existing technology? >=20 > This is a requirements document, so that it doesn't specify > solutions. However, as described above I would > like to see a more in-depth discussion of the capabilities and > limitations of existing technology. Noted, I tried to improve the text in a number of places. > 6. [snip] >=20 > 7. Is the solution sufficiently configurable?/an >=20 > While the document focuses on requirements rather than solutions, I > do think it would be valuable to > discuss the potential service provider objectives in more detail. > For example, specifying exit and > entry points is a means, not an end. Within the CDN space, we have > come to understand that the "best" > server may depend on whether the goal is to optimize latency or > throughput. Understood. Draft-08 may still have places where these objectives need to be expanded. > 8. [snip] >=20 > 9. [snip] >=20 > 10. Is Security Management discussed? >=20 > Section 5 discusses security requirements. Note that since the > publication of RFC 3263, a number of additional documents > have been dealt with the issue of TLS session establishment. These > documents (such as draft-ietf-sip-sips) may be worth > referencing in addition to RFC 3263 within Section 3.2: >=20 > The mechanisms recommended for locating a peer's SBE MUST be > able > to convey how a peer should initiate secure session > establishment. >=20 > Notes : some mechanisms exist. For example, the required > protocol > use of SIP over TLS may be discovered via [RFC3263]. Yes, good point. New text says: It is desirable for an SSP to be able to communicate how authentication of a peer's SBEs will occur (see the security requirements for more details). o Requirement #6: The mechanisms recommended for locating a peer's SBE MUST be able to convey how a peer should initiate secure session establishment. Notes: some mechanisms exist. For example, the required protocol use of SIP over TLS may be discovered via [RFC3263] and guidelines concerning the use of the SIPS URI scheme in SIP have been documented in [I-D.ietf-sip-sips]. From hmmr@cisco.com Mon Oct 26 07:04:09 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6BF028C2AD for ; Mon, 26 Oct 2009 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OomHaFnfMR6w for ; Mon, 26 Oct 2009 07:04:08 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7F54628C2AC for ; Mon, 26 Oct 2009 07:04:08 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEALZI5UqrR7Ht/2dsb2JhbACPbLFElnCCQIF/BA X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="217838934" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 26 Oct 2009 14:04:21 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QE4LhK008384; Mon, 26 Oct 2009 14:04:21 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:04:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 10:04:19 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3084E0CCF@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF1E1@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] OPS-DIR review from Bernard Aboba ondraft-ietf-speermint-requirements-08 Thread-Index: AcpWJP68gHGJeBlYSDCBvT1HIH7zGwAAAVawAAgGeaA= References: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF1E0@srvxchg3.cablelabs.com> <9AAEDF491EF7CA48AB587781B8F5D7C6024FF1E1@srvxchg3.cablelabs.com> From: "Mike Hammer (hmmr)" To: "Jean-Francois Mule" , "Bernard Aboba" X-OriginalArrivalTime: 26 Oct 2009 14:04:20.0983 (UTC) FILETIME=[370D4870:01CA5645] Cc: speermint@ietf.org Subject: Re: [Speermint] OPS-DIR review from Bernard Aboba ondraft-ietf-speermint-requirements-08 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:04:09 -0000 Notes: some mechanisms exist. For example, the required protocol use of SIP over TLS may be discovered via [RFC3263] and guidelines concerning the use of the SIPS URI scheme in SIP have been documented in [I-D.ietf-sip-sips]. SIP-SIPS is now out as RFC 5630. Mike > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On > Behalf Of Jean-Francois Mule > Sent: Monday, October 26, 2009 7:11 AM > To: Bernard Aboba > Cc: speermint@ietf.org > Subject: Re: [Speermint] OPS-DIR review from Bernard Aboba ondraft-ietf- > speermint-requirements-08 >=20 > First, thank you Bernard for the OPS-DIR review on this draft from > speermint. >=20 > I apologize for the delay in my response to you. > You had provided these comments before the last IETF and I waited for > the IESG reviews that came in 2 weeks ago to address them. >=20 > I will be submitting draft-08 which does address your comments (at least > most of them). > I may release another update after the IETF in Hiroshima based on the > feedback I receive, especially to add more background on some of the > requirements (and to fully address some of your notes). >=20 > Details inline below. >=20 > Thank you, > Jean-Francois > jfm@cablelabs.com > --- > On Tue Jun 30 09:38:23 PDT 2009, Bernard Aboba bernard_aboba at > hotmail.com wrote: > > Review Summary: > > Intended status: Informational > > > > This document discusses requirements for session peering in voice, > > presence, instant messaging and multimedia. > > > > 1. Is the document readable? > > > > In general, the document provides a readable listing of > > requirements. However additional background on the requirements > > could have been provided, which would make the document easier to > > understand. >=20 > Yes. I've updated the introduction to point to the reader to background > documents: > "A number of documents have been developed to provide > additional background information about SIP session > peering. It is expected that the reader is familiar > with the reference architecture described in > > and use cases which describe how session peering > has been or could be deployed for voice ( target=3D"I-D.ietf-speermint-voip-consolidated-usecases"/>) > and instant messaging and presence > ()." >=20 >=20 > I understand your comment to also mean that some background is lacking > on specific requirements. I've updated a few, and plan to do more > editing in the next revision based on WG feedback. >=20 >=20 > > 2. Does it contain nits? > > > > Yes. See below. > Fixed these and a few others, thank you for catching those. >=20 >=20 > > 3. Is the document class appropriate? > > > > Yes. > > > > 4. Does the document consider existing solutions? > > > > This is a requirements document, so it largely focuses on > > requirements rather than solutions. > > > > However, there are instances where the document does not > > sufficiently discuss existing practices. > The exciting DNS practices for *SIP traffic exchanges* as discussed > inside the Speermint WG have been captured to the best of my knowledge. > When we started this work, it was not uncommon to find IP addresses in > SIP URIs (and some still do). Sections like 3.3.1. reinforce the use of > DNS. >=20 >=20 > > For example, in Section 3.2 the document refers to limitations of > > DNS in providing different responses based on the querier: > > > > "However, this DNS-based solution may be limited > > in cases where the DNS response varies based on who sends the > > query (peer-dependent SBEs, see below).... > > > > Notes on solution space: > > For advertising peer-dependent SBEs (peer variability), the > > solution space based on [RFC3263] is under specified and there are > > no know best current practices. Is DNS the right place for > > putting data that varies based on who asks?" > > > > Content Distribution Networks (CDNs) have quite a bit of > > operational experience with use of DNS to provide > > "data that varies based on who asks". Information on existing > > approaches is provided in RFCs 3466, 3568, > > and 3570. CDNs also have experience in use of application re-direct > > for global load balancing. I was > > therefore somewhat surprised that this document did not discuss or > > reference work on CDNs. > > > > While the document focuses on layer 5 peering, it does seem like it > > would be worthwhile to at least have > > some discussion of lower layer load balancing techniques such as > > anycast (e.g. RFC 4786), which when > > combined with DNS can be used to provide "data that varies based on > > who asks". >=20 > Your comment below points are insightful and they point to one aspect of > this draft, the use of RFC3263 and DNS to locate the SIP signaling > entities of your peers and how peers can give different entry points > using DNS. >=20 > I've read the references and see the benefits of pointing out those in > the notes about the solution space. I made a few edits to capture them > in draft-08. In particular, the new text for req#4 says: >=20 > o Requirement #4: > The mechanisms recommended for the declaration or advertisement of > SBE and DBE entities MUST allow for peer variability. >=20 > Notes on solution space: > A simple solution is to advertise SBE entities using DNS and > [RFC3263] by providing different DNS names to different peers. > This approach has some practical limitations because the SIP URIs > containing the DNS names used to resolve the SBEs may be > propagated by users, for example in the form of sip:user@domain. > It is impractical to ask users to use different target URIs based > upon their SIP service provider's desire to receive incoming > session signaling at different ingress SBEs based upon the > originator. The solution described in [RFC3263] and based on DNS > to advertise SBEs is therefore under-specified for this > requirement. > Other DNS mechanisms have been used extensively in other areas of > the Internet, in particular in Content Distribution > Internetworking to make the DNS responses vary based on the > originator of the DNS query (see [RFC3466], [RFC3568] and > [RFC3570]). The applicability of such solutions needs for session > peering needs further analysis. > Finally, other techniques such as Anycast services ([RFC4786]) may > be employed at lower layers than Layer 5 to provide a solution to > this requirement. For example, anycast nodes could be defined by > SIP service providers to expose a common address for SBEs into > DNS, allowing the resolution of the anycast node address to the > appropriate peer-dependent service address based on the routing > topology or other criteria gathered from the combined use of > anycast and DNS techniques. >=20 > Let me know if this is a first step to address your comment. > I am not sure about putting more details on the solutions used in CDN > networks in this document given the document's intent to catalog the > solution space along with requirements. I welcome more feedback. >=20 >=20 > > 5. Does the solution break existing technology? > > > > This is a requirements document, so that it doesn't specify > > solutions. However, as described above I would > > like to see a more in-depth discussion of the capabilities and > > limitations of existing technology. >=20 > Noted, I tried to improve the text in a number of places. >=20 > > 6. [snip] > > > > 7. Is the solution sufficiently configurable?/an > > > > While the document focuses on requirements rather than solutions, I > > do think it would be valuable to > > discuss the potential service provider objectives in more detail. > > For example, specifying exit and > > entry points is a means, not an end. Within the CDN space, we have > > come to understand that the "best" > > server may depend on whether the goal is to optimize latency or > > throughput. >=20 > Understood. Draft-08 may still have places where these objectives need > to be expanded. >=20 > > 8. [snip] > > > > 9. [snip] > > > > 10. Is Security Management discussed? > > > > Section 5 discusses security requirements. Note that since the > > publication of RFC 3263, a number of additional documents > > have been dealt with the issue of TLS session establishment. These > > documents (such as draft-ietf-sip-sips) may be worth > > referencing in addition to RFC 3263 within Section 3.2: > > > > The mechanisms recommended for locating a peer's SBE MUST be > > able > > to convey how a peer should initiate secure session > > establishment. > > > > Notes : some mechanisms exist. For example, the required > > protocol > > use of SIP over TLS may be discovered via [RFC3263]. >=20 > Yes, good point. > New text says: > It is desirable for an SSP to be able to communicate how > authentication of a peer's SBEs will occur (see the security > requirements for more details). >=20 > o Requirement #6: > The mechanisms recommended for locating a peer's SBE MUST be able > to convey how a peer should initiate secure session establishment. >=20 > Notes: some mechanisms exist. For example, the required protocol > use of SIP over TLS may be discovered via [RFC3263] and guidelines > concerning the use of the SIPS URI scheme in SIP have been > documented in [I-D.ietf-sip-sips]. > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint From jf.mule@cablelabs.com Mon Oct 26 10:36:34 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDCB3A6B2E for ; Mon, 26 Oct 2009 10:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7aHrPgV6LZp for ; Mon, 26 Oct 2009 10:36:32 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B86E53A68F5 for ; Mon, 26 Oct 2009 10:36:32 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n9QHaj8J003913; Mon, 26 Oct 2009 11:36:45 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 26 Oct 2009 11:36:45 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 11:36:28 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF21E@srvxchg3.cablelabs.com> In-Reply-To: <4ACB6A6F.9030200@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] requirements for presence and IM peering Thread-Index: AcpGnqJhBtDRrqCdT7a4TGHhCu5SkAPww0CQ References: <4ACB6A6F.9030200@stpeter.im> From: "Jean-Francois Mule" To: "Peter Saint-Andre" X-Approved: ondar Cc: speermint@ietf.org Subject: Re: [Speermint] requirements for presence and IM peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:36:34 -0000 Peter, Thank you for your review and for sending those comments to the list. See my responses inline - let me know if the resolution looks ok to you. Jean-Francois. > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint- > bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: Tuesday, October 06, 2009 10:04 AM > To: speermint@ietf.org > Subject: [Speermint] requirements for presence and IM peering >=20 > Section 4 of draft-ietf-speermint-requirements contains > requirements for > peering of presence and instant messaging in SIP-based systems. > Here is > some feedback regarding those requirements. >=20 > In general, I am concerned about the use of the capitalized keyword > MUST > in these requirements, because it could be taken to override local > policies or user-level privacy settings. For example, if we say > that an > entity absolutely MUST be allowed to subscribe to the presence of > users > in another SSP then operators might take that as saying that a user > or a > service-wide admin cannot block an entity from another SSP (or all > entities from another SSP) from subscribing to the user's presence. > I > don't think this is what we mean here, but we need to make that > clear. >=20 > Some specific comments follow. >=20 > Requirement #10 >=20 > The mechanisms recommended for the exchange of presence > information between SSPs MUST allow a user of one SSP's > presence > community to subscribe presentities served by another SSP via > its > local community, including subscriptions to a single > presentity, a > personal, public or ad-hoc group list of presentities. >=20 > The phrase "to subscribe presentities" is missing some words. I > think > "to subscribe to presentities" is meant. However, I think it is > better > to say "to send a presence subscription request to presentities" > because > presumably the presentity needs to control who can and cannot see > its > presence information via some explicit approval mechanism. Agreed on both the requirement verb (changed MUST to SHOULD for the reasons you invoke), and the text change. New text for Requirement 10 now says: The mechanisms recommended for the exchange of presence information between SSPs SHOULD allow a user of one presence community to send a presence subscription request to presentities served by another SSP via its local community, including subscriptions to a single presentity, a personal, public or ad-hoc group list of presentities. >=20 > Requirement #11 >=20 > The mechanisms recommended for Instant Messaging message > exchanges > between SSPs MUST allow a user of one SSP's community to > communicate with users of the other SSP community via their > local > community using various methods. Such methods include > sending a > one-time IM message, initiating a SIP session for > transporting > sessions of messages, participating in n-way chats using chat > rooms with users from the peer SSPs, sending a file or > sharing a > document. >=20 > Use cases such as sending a file and sharing a document are not IM > use > cases. Furthermore, the text seems to imply that an SSP cannot > exercise > any granular control over which of the "various methods" are > allowed. In > my experience, an SSP might allow IMs but not groupchats, textual > communication (IM and groupchat) but not sending files, etc. Ok, changed the requirement #11 to be: The mechanisms recommended for Instant Messaging exchanges between SSPs SHOULD allow a user of one SSP's community to communicate with users of the other SSP community via their local community using the various methods. Note that some SSPs may exercise some control over which methods are allowed based on service policies. >=20 > Requirement #12 >=20 > In order to enable sending less notifications between > communities, > there should be a mechanism that will enable sharing privacy > information of users between the communities. This will > enable > sending a single notification per presentity that will be > sent to > the appropriate watchers on the other community according to > the > presentity's privacy information. > The privacy sharing mechanism must be done in a way that will > enable getting the consent of the user whose privacy will be > sent > to the other community prior to sending the privacy > information. > if user consent is not give, it should not be possible to > this > optimization. In addition to getting the consent of users > regarding privacy sharing, the privacy data must be sent only > via > secure channels between communities. >=20 > Usage: "less ... notifications" =3D=3D> "fewer ... notifications". >=20 > Typos: "if user consent is not give, it should not be possible to > this > optimization." =3D=3D> "If user consent is not given, it should not be > possible to use this optimization." >=20 > The phrase "secure channels" is not defined. Does this mean SIP > signalling over TLS-encrypted TCP? It would be good to specify > what's > meant, or to point to the security considerations. Thank you for the comment; this requirement needed a good rewrite. The new text says: o Requirement #12: Privacy Sharing In some presence communities, users can define the list of watchers that receive presence notifications for a given presentity. Such privacy settings for watcher notifications per presentity are typically not shared across SSPs causing multiple notifications to be sent for one presentity change between SSPs. The sharing of those privacy settings per presentity between SSPs would allow fewer notifications: a single notification would be sent per presentity and the terminating SSP would send notifications to the appropriate watchers according to the presentity's privacy information. The mechanisms recommended for Presence information exchanges between SSPs SHOULD allow the sharing of some user privacy settings in order for users to convey the list of watchers that can receive notification of presence information changes on a per presentity basis. The privacy sharing mechanism must be done with the express consent of the user whose privacy settings will be shared with to the other community. Because of the privacy-sensitive information exchanged between SSPs, the protocols used for this exchange must follow the security recommendations defined in section 6 of [RFC3863]. > Requirement #13 >=20 > It should be possible to send a presence document with a list > of > watchers on the other community that should receive the > presence > document notification. This will enable sending less > presence > document notifications between the communities while avoiding > the > need to share privacy information of presentities from one > community to the other. >=20 > Usage: "less ... notifications" =3D=3D> "fewer ... notifications". >=20 > This requirement says nothing about security. Presumably, > information > about the recipients of a given notification might also be private > and > therefore worthy of protection, just as under Requirement #12. ok, the note now in req #12 should address this: Because of the privacy-sensitive information exchanged between SSPs, the protocols used for the exchange of presence information must follow the security recommendations defined in section 6 of . >=20 > Requirement #14 >=20 > Early deployments of SIP based presence and IM gateways are > done > in front of legacy proprietary systems that use different > names > for different properties that exist in PIDF. For example "Do > Not > Disturb" may be translated to "Busy" in another system. In > order > to make sure that the meaning of the status is preserved, > there is > a need that either each system will translate its internal > statuses to standard PIDF based statuses of a translation > table of proprietary statuses to standard based PIDF statuses will > be provided from one system to the other. >=20 > Usage: In "different names for different properties" I would change > the second instance of "different" to "various". >=20 > The final sentence is a bit confusing and its directive to SSPs is > not clear, even if we correct "of" to "or" in the middle. I might > reword it > as follows: >=20 > To make sure that the meaning of the status is preserved, an > SSP should translate its internal statuses to standard PIDF > statuses. >=20 > I don't think we want to recommend that SSPs exchange translation > tables, because the maintenance issues are significant and there is > no need to do this given that we have PIDF. Agreed, dropped the alternative to exchange translation tables. The new text now says: o Requirement #14: Standard PIDF Documents and Mappings Early deployments of SIP-based presence and Instant Messaging gateways have been done in front of legacy proprietary systems that use different naming schemes or name values for the elements and properties defined in a Presence Information Data Format (PIDF) document ([RFC3863]). For example the status value "Do Not Disturb" in one presence service may be mapped to "Busy" in another system. Beyond this example of status values, the meaning of the presence information should be preserved between SSPs. The systems used to exchange presence documents between peers SHOULD use standard PIDF documents and translate any non-standard value of a PIDF element to a standard one. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ From root@core3.amsl.com Mon Oct 26 11:00:01 2009 Return-Path: X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D6DB43A6831; Mon, 26 Oct 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026180001.D6DB43A6831@core3.amsl.com> Date: Mon, 26 Oct 2009 11:00:01 -0700 (PDT) Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-requirements-08.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Requirements for SIP-based Session Peering Author(s) : J. Mule Filename : draft-ietf-speermint-requirements-08.txt Pages : 27 Date : 2009-10-26 This memo captures protocol requirements to enable session peering of voice, presence, instant messaging and other types of multimedia traffic. It is based on the use cases that have been described in the SPEERMINT working group. This informational document is intended to link the session peering use cases to protocol solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-speermint-requirements-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26105341.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 11:15:02 2009 Return-Path: X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AAB593A6996; Mon, 26 Oct 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026181502.AAB593A6996@core3.amsl.com> Date: Mon, 26 Oct 2009 11:15:02 -0700 (PDT) Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-requirements-09.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Requirements for SIP-based Session Peering Author(s) : J. Mule Filename : draft-ietf-speermint-requirements-09.txt Pages : 27 Date : 2009-10-26 This memo captures protocol requirements to enable session peering of voice, presence, instant messaging and other types of multimedia traffic. It is based on the use cases that have been described in the SPEERMINT working group. This informational document is intended to link the session peering use cases to protocol solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-speermint-requirements-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26110450.I-D@ietf.org> --NextPart-- From jf.mule@cablelabs.com Mon Oct 26 11:15:44 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DCA3A69A0 for ; Mon, 26 Oct 2009 11:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52gvMKjHQczR for ; Mon, 26 Oct 2009 11:15:43 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 22E6A3A68E7 for ; Mon, 26 Oct 2009 11:15:42 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n9QIFt7k007958 for ; Mon, 26 Oct 2009 12:15:55 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 26 Oct 2009 12:15:55 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 12:15:51 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF230@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of requirements draft to address IESG, ops-dir and other reviews Thread-Index: AcpWaFnnWKJ3uKxKQpWBxgSImRKdVg== From: "Jean-Francois Mule" To: X-Approved: ondar Subject: [Speermint] New version of requirements draft to address IESG, ops-dir and other reviews X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:15:44 -0000 I have submitted a revision of draft-ietf-speermint-requirements to address comments received from Bernard Aboba, Peter Saint-Andre and IESG members. See http://www.ietf.org/id/draft-ietf-speermint-requirements-09.txt and the HTML diff tool. The changes include: a) editorial changes Nits, typos and other editorial changes requested to provide more background. =20 b) references to DNS and anycast services=20 Robert Sparks' IESG comment as well as Bernard Aboba's ops-dir comments made me to reference some of the work done in CDNs and the use of anycast as part of the solution space for providing peer variability (providing different SBE-DBE to different peers). c) IM and presence comments from Peter Saint-Andre The revision contains some text rewrite of the IM and presence requirements because the previous text had broken English. Some technical changes in a few requirements did happen there too - see other email sent today in response to Peter's comments. Comments and feedback are welcome on those changes. Jean-Francois. From jason_livingood@cable.comcast.com Mon Oct 26 12:28:56 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52393A6AFC for ; Mon, 26 Oct 2009 12:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=2.294, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8h-kCQa3NCP for ; Mon, 26 Oct 2009 12:28:54 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id EC2373A6AE7 for ; Mon, 26 Oct 2009 12:28:53 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.58514051; Mon, 26 Oct 2009 15:29:04 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 15:29:05 -0400 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Oct 2009 19:29:05 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 15:29:04 -0400 From: Jason Livingood To: Message-ID: Thread-Topic: draft-hancock-sip-interconnect-guidelines to a WG item? Thread-Index: AcpWcpPVIt7qnuWVLU+9wD4kCKk3AA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339415744_514138" X-OriginalArrivalTime: 26 Oct 2009 19:29:05.0764 (UTC) FILETIME=[94E2EA40:01CA5672] Subject: [Speermint] draft-hancock-sip-interconnect-guidelines to a WG item? X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:28:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339415744_514138 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable At the last meeting we had a request to make draft-hancock-sip-interconnect-guidelines-01 an official working group item= . I didn=B9t hear any loud objections to that but wanted to ask again here. If you have any concerns about whether this should become a WG, please advise. Thanks Jason --B_3339415744_514138 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable draft-hancock-sip-interconnect-guidelines to a WG item? At the last meeting we had a request to make draft-hancock-sip-interconnec= t-guidelines-01 an official working group item.  I didn’t hear an= y loud objections to that but wanted to ask again here.  If you have an= y concerns about whether this should become a WG, please advise.

Thanks
Jason --B_3339415744_514138-- From richard@shockey.us Mon Oct 26 13:48:18 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F4928C36B for ; Mon, 26 Oct 2009 13:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBRmQVi93nwE for ; Mon, 26 Oct 2009 13:48:14 -0700 (PDT) Received: from outbound-mail-33.bluehost.com (outbound-mail-33.bluehost.com [69.89.18.153]) by core3.amsl.com (Postfix) with SMTP id D40073A6781 for ; Mon, 26 Oct 2009 13:48:14 -0700 (PDT) Received: (qmail 21046 invoked by uid 0); 26 Oct 2009 20:48:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 26 Oct 2009 20:48:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Ui4XCjCNDWryrkDHEOwi0NJpL0NskSGArGluugY/ygrGEqKBAmR1F6I0NPDrAsrRCVzFpOtK6Po50+QwcOXLdZe687xX9dHEQBX+31xRjR4HuLGAXZSN2fupq6RBtmBq; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2WUO-0000D3-4U; Mon, 26 Oct 2009 14:48:28 -0600 From: "Richard Shockey" To: "'Jason Livingood'" , References: In-Reply-To: Date: Mon, 26 Oct 2009 16:48:26 -0400 Message-ID: <062b01ca567d$ab2e7610$018b6230$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_062C_01CA565C.241CD610" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpWcpPVIt7qnuWVLU+9wD4kCKk3AAACwtzw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Subject: Re: [Speermint] draft-hancock-sip-interconnect-guidelines to a WG item? X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:48:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_062C_01CA565C.241CD610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 This should be a WG item. From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Jason Livingood Sent: Monday, October 26, 2009 3:29 PM To: speermint@ietf.org Subject: [Speermint] draft-hancock-sip-interconnect-guidelines to a WG item? At the last meeting we had a request to make draft-hancock-sip-interconnect-guidelines-01 an official working group item. I didn't hear any loud objections to that but wanted to ask again here. If you have any concerns about whether this should become a WG, please advise. Thanks Jason ------=_NextPart_000_062C_01CA565C.241CD610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-hancock-sip-interconnect-guidelines to a WG item?

+1   This should be a WG = item.

 

From:= speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On = Behalf Of Jason Livingood
Sent: Monday, October 26, 2009 3:29 PM
To: speermint@ietf.org
Subject: [Speermint] draft-hancock-sip-interconnect-guidelines to = a WG item?

 

At the last meeting we had a request to make draft-hancock-sip-interconnect-guidelines-01 an official working group = item.  I didn’t hear any loud objections to that but wanted to ask = again here.  If you have any concerns about whether this should become a WG, = please advise.

Thanks
Jason

------=_NextPart_000_062C_01CA565C.241CD610-- From victor.pascual.avila@gmail.com Tue Oct 27 08:14:37 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAE63A6975 for ; Tue, 27 Oct 2009 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RheUEjq2JFYp for ; Tue, 27 Oct 2009 08:14:37 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by core3.amsl.com (Postfix) with ESMTP id EA6CC28C0F0 for ; Tue, 27 Oct 2009 08:14:35 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id e6so59364gvc.15 for ; Tue, 27 Oct 2009 08:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=85mezIKBygGLAf818NLcLmFU1SAORUvsplPvyblFhAQ=; b=lRnUqdLgWBWnCY7jA0zHlLwiZ0Y6/72eVi9FZ/nSgTAVi1weNKgdd6N2TXFZ9ZxjUg iKrFotP7pdtom8r1Z+TNKHtYOJoy+6CttboZa7n/EBzlfHkBqUkfooYOHenQhABAnl7f fCgMpM8hWpeOras7T4ZNMfCuib08UPMj4fgbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=whNvMKs9kf2jtbpwGfZft48cX631ZTZq8igWEV+8OH31htnEOCbood9gmECseogGEK pP34pgkSzZiFMBHc898mlA6dCwvE0vEb+oQR+3PT2iIzKdXjHY3lC7YC0GSwxXSFBFN0 ycgTZ/d8RT4sG4D/Au+0iR1xtfSYHTGzpUKRg= MIME-Version: 1.0 Received: by 10.216.85.210 with SMTP id u60mr5629602wee.226.1256656486853; Tue, 27 Oct 2009 08:14:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Oct 2009 16:14:46 +0100 Message-ID: <618e24240910270814t3c210a4fg505edb8318fe68c7@mail.gmail.com> From: Victor Pascual Avila To: Jason Livingood Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: speermint@ietf.org Subject: Re: [Speermint] draft-hancock-sip-interconnect-guidelines to a WG item? X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:14:37 -0000 While "emergency calls" is not addressed in the document, IMHO it would be useful to define whether the Resource-Priority header field should be honored, specially in section 4.5.2 Thanks, -Victor On Mon, Oct 26, 2009 at 8:29 PM, Jason Livingood wrote: > At the last meeting we had a request to make > draft-hancock-sip-interconnect-guidelines-01 an official working group it= em. > =C2=A0I didn=E2=80=99t hear any loud objections to that but wanted to ask= again here. =C2=A0If > you have any concerns about whether this should become a WG, please advis= e. > > Thanks > Jason > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint > > --=20 Victor Pascual =C3=81vila From D.Malas@cablelabs.com Tue Oct 27 16:04:38 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3223A6A2C for ; Tue, 27 Oct 2009 16:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZNbsOVT29hY for ; Tue, 27 Oct 2009 16:04:37 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B61483A69B6 for ; Tue, 27 Oct 2009 16:04:37 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n9RN4qoO028575 for ; Tue, 27 Oct 2009 17:04:52 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 27 Oct 2009 17:04:52 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.4.10.173 ([10.4.10.173]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Oct 2009 23:04:52 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 17:04:51 -0600 From: Daryl Malas To: Message-ID: Thread-Topic: [Speermint] FW: [Enum] FW: I-D Action:draft-malas-enum-trunk-sip-01.txt Thread-Index: AcpWf280Kd71k8ahR1mA52VAwlSZfQAC6pbAADOybR8= In-Reply-To: <06e601ca568b$23dd29a0$6b977ce0$@us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Subject: [Speermint] FW: [Enum] FW: I-D Action:draft-malas-enum-trunk-sip-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 23:04:38 -0000 All, We submitted a draft for including RFC 4904 parameters in an ENUM NAPTR response. I think this is applicable to peering. Let us know if you have any comments. Regards, Daryl -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 26, 2009 5:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-malas-enum-trunk-sip-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Trunk Group Use in ENUM Author(s) : D. Malas, T. Creighton Filename : draft-malas-enum-trunk-sip-01.txt Pages : 9 Date : 2009-10-26 This document describes a method for incorporating trunk group parameters into an E.164 Number Mapping (ENUM) response for the Session Initiation Protocol (SIP) [RFC3261] service URI. It defines the use of trunk group contexts as defined in [RFC4904] as additional parameters in the E2U+SIP enumservice NAPTR record [RFC3403] URI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-enum-trunk-sip-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum ------ End of Forwarded Message From jason_livingood@cable.comcast.com Wed Oct 28 13:44:44 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2463A6A63 for ; Wed, 28 Oct 2009 13:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY1r3a-zM6iI for ; Wed, 28 Oct 2009 13:44:42 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id AB9323A6A6A for ; Wed, 28 Oct 2009 13:44:42 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.81469475; Wed, 28 Oct 2009 16:44:41 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 16:44:42 -0400 Received: from 147.191.227.143 ([147.191.227.143]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Oct 2009 20:44:42 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 28 Oct 2009 16:44:41 -0400 From: Jason Livingood To: Message-ID: Thread-Topic: Agenda Uploaded Thread-Index: AcpYD3jsvjABvT5Yr0iJuJxgJQfsvQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339593081_3900674" X-OriginalArrivalTime: 28 Oct 2009 20:44:42.0766 (UTC) FILETIME=[79F9FAE0:01CA580F] Subject: [Speermint] Agenda Uploaded X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:44:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339593081_3900674 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The draft agenda for IETF 76 has been uploaded and is available at http://www.ietf.org/proceedings/09nov/agenda/speermint.txt This is what the content of the file is: Session PEERing for Multimedia INTerconnect (SPEERMINT) Hiroshima, Japan Tuesday, November 11, 2009 - Afternoon Session I - 1300 to 1500 hours local time Room Name: Camellia ============================================================================ ================== CHAIRS: Jason Livingood Daryl Malas SECRETARY: Alexander Mayrhofer RAI AREA DIRECTORS: Cullen Jennings Robert Sparks RAI AREA ADVISOR: Cullen Jennings GENERAL (15 minutes) 1 - Welcome & Introduction to SPEERMINT / Administrivia 5 minutes (1300 - 1305) - Mailing list: speermint-request@ietf.org - Scribe (jabber) - Blue Sheets Daryl Malas 2 - SPEERMINT Peering Architecture 55 minutes (1315 - 1325) http://tools.ietf.org/html/draft-ietf-speermint-architecture-09 TBD Presenter 3 - SPEERMINT Message Flows 60 minutes (1325 - 1335) http://tools.ietf.org/html/draft-ietf-speermint-flows-06 TBD Presenter NOTE: Our approach on the two drafts above is to have an editor open the document for live editing. The WG chairs or editor will then walk us through a section-by-section review of the document. We want to produce an updated version following the meeting that is then ready for WGLC. --B_3339593081_3900674 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Agenda Uploaded The draft agenda for IETF 76 has been uploaded and is available at http://www.iet= f.org/proceedings/09nov/agenda/speermint.txt

This is what the content of the file is:

Session PEERing for Multimedia INTerconnect (SPEERMINT)

Hiroshima, Japan
Tuesday, November 11, 2009 - Afternoon Session I - 1300 to 1500 hours local= time
Room Name: Camellia
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIRS:          Jason Livingo= od   <jason_livingo= od@cable.comcast.com>
   Daryl Malas  <d.malas@cablelabs.com>

SECRETARY:    Alexander Mayrhofer  <alexander.mayrhofer@nic.at>

RAI AREA DIRECTORS: Cullen Jennings  <fluffy@cisco.com>
   Robert Sparks   <rjsparks@nostrum.com>

RAI AREA ADVISOR: Cullen Jennings  <fluffy@cisco.com>


GENERAL (15 minutes)

1 - Welcome & Introduction to SPEERMINT / Administrivia   &nb= sp;5 minutes (1300 - 1305)
    - Mailing list: speermint-request@ietf.org
   - Scribe (jabber)
    - Blue Sheets
 Daryl Malas

2 - SPEERMINT Peering Architecture     55 minutes = (1315 - 1325)
 http://tools.ietf.org/html/draft-ietf-speermint-architecture-09
 TBD Presenter

3 - SPEERMINT Message Flows      60 minutes (= 1325 - 1335)
 ht= tp://tools.ietf.org/html/draft-ietf-speermint-flows-06
 TBD Presenter

NOTE: Our approach on the two drafts above is to have an editor open the do= cument for live editing.  The WG chairs or editor will then walk us thr= ough a section-by-section review of the document.  We want to produce a= n updated version following the meeting that is then ready for WGLC.  <= BR>

  --B_3339593081_3900674-- From stpeter@stpeter.im Wed Oct 28 13:52:36 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8AD53A6A6D for ; Wed, 28 Oct 2009 13:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mmAoiM3KHNA for ; Wed, 28 Oct 2009 13:52:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3E5FA3A686C for ; Wed, 28 Oct 2009 13:52:36 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 99A564008F; Wed, 28 Oct 2009 14:52:51 -0600 (MDT) Message-ID: <4AE8AF22.2080701@stpeter.im> Date: Wed, 28 Oct 2009 14:52:50 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jean-Francois Mule References: <4ACB6A6F.9030200@stpeter.im> <9AAEDF491EF7CA48AB587781B8F5D7C6024FF21E@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6024FF21E@srvxchg3.cablelabs.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: speermint@ietf.org Subject: Re: [Speermint] requirements for presence and IM peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:52:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/26/09 11:36 AM, Jean-Francois Mule wrote: > Peter, > > Thank you for your review and for sending those comments to the list. > See my responses inline - let me know if the resolution looks ok to you. Thank you, Jean-Francois. All of your resolutions address my concerns. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkroryIACgkQNL8k5A2w/vw47wCfV9LtvzOs5JJU47zWVKARl8+1 pLsAoM9BXjlnCfNqfH0o49Hx5c226xgE =q9YF -----END PGP SIGNATURE-----