Re: [Speermint] draft-houri-speermint-rtc-provisioning-reqs-00.txt
Avshalom Houri <AVSHALOM@il.ibm.com> Mon, 18 September 2006 01:45 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8CQ-0006zh-MT; Sun, 17 Sep 2006 21:45:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8CP-0006y5-2d for speermint@ietf.org; Sun, 17 Sep 2006 21:45:29 -0400
Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP8CM-0008Ds-9W for speermint@ietf.org; Sun, 17 Sep 2006 21:45:29 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id k8I1jPCl044910 for <speermint@ietf.org>; Mon, 18 Sep 2006 01:45:25 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k8I1o8k42937064 for <speermint@ietf.org>; Mon, 18 Sep 2006 03:50:08 +0200
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k8I1jPic007963 for <speermint@ietf.org>; Mon, 18 Sep 2006 03:45:25 +0200
Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k8I1jPpG007960 for <speermint@ietf.org>; Mon, 18 Sep 2006 03:45:25 +0200
In-Reply-To: <CD6CE349CFD30D40BF5E13B3E0D8480401BADCAD@srvxchg.cablelabs.com>
To: speermint@ietf.org
MIME-Version: 1.0
Subject: Re: [Speermint] draft-houri-speermint-rtc-provisioning-reqs-00.txt
X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006
From: Avshalom Houri <AVSHALOM@il.ibm.com>
Message-ID: <OF5192C877.4F87A238-ONC22571ED.0009129F-C22571ED.0009A6C4@il.ibm.com>
Date: Mon, 18 Sep 2006 04:50:06 +0300
X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 18/09/2006 04:50:08, Serialize complete at 18/09/2006 04:50:08
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0588810077=="
Errors-To: speermint-bounces@ietf.org
Jean-Francois While it is easy to conclude that the document has to be rewritten and incorporate your's and Hannes's comments I am still not sure where this type of requirements that are coming from a certain application as presence and IM should fit. Should they be part of the general requirements document? Should the be a use case document? We should discuss this question in the interim. Another issue that I have is that I did not see any reference to presence and IM in the terminology, requirements and architecture documents. I think that it was concluded that SPEARMINT is not only for VOIP but VOIP is the only example that is being used. --Avshalom "Jean-Francois Mule" <jf.mule@cablelabs.com> 15/09/2006 01:27 To Avshalom Houri/Haifa/IBM@IBMIL cc <speermint@ietf.org>, <aoki@aol.net>, <timrang@microsoft.com> Subject [Speermint] draft-houri-speermint-rtc-provisioning-reqs-00.txt Avshalom, I read through your draft and here are a few comments. I need more input and feedback from the wg in order to understand what sub-sets of requirements should be refined and added to the main requirement doc for VoIP interconnect. --- Terminology alignment As Hannes pointed out, it would be a plus if you could update the document to use the terminology proposed in speermint. That said, I think we can all map the "single community" to a "peer network". The latter includes users but that should be ok. While I am familiar with clearinghouses for RTC and VoIP traffic in particular, I am not sure it adds value in speermint and some of your requirements related to clearinghouses could be isolated to peer networks (ADD-REQ-006, ADD-REQ-008). I would recommend presenting this as a special case or example of a federation where one member of the federation has a special role of enforcing some federation and peer policies. --- Core requirements You wrote: | CORE-REQ-001: It should be possible to push and pull | provisioning data between communities ^^^^^^^^^^^^^^^^^ s/communities/peer networks Some 'data' has to be exchanged between peers to enable session peering but the provisioning models vary based on the solutions and may not require push or pull directly between the providers. End users may provide some URIs with domain names which suffice to enable session peering if the domain is RFC3263-enabled in case of SIP URIs for e.g. Or, providers may just configure DNS for their respective domain names appropriately (there may be a pull from DNS). In short, depending on the session peering models, a pull or push of data between peer networks may not be necessary. | CORE-REQ-002: It should be possible to secure the pushing and pulling | of provisioning data. Provisioning data should be provided only to | the appropriate community and only on a need to know basis. This again is arguable. As we have discussed in the context speermint, a domain name should be resolvable in the public DNS (the domain's IPs may not be reachable by all though). So some provisioning data may be shared with everyone, it all depends on the peer network policies. | CORE-REQ-003: It should be possible to provide the FQDN of the edge | proxies of the other community. Ok; this could be automated too (3263?). (snip) | CORE-REQ-006: It should be possible to provide the details of the | certificates that are expected by the other community. I.e. common | name, certificate issuer and expiration. You clearly have some specific applications in mind with certain trust models between peer networks in support of them. Etc. In conclusion, I'm having a hard time understanding how these high-level and general requirements fit in and whether they can be met without providing more details on the applications and your assumptions. Jean-Francois.
_______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint
- [Speermint] draft-houri-speermint-rtc-provisionin… Jean-Francois Mule
- Re: [Speermint] draft-houri-speermint-rtc-provisi… Avshalom Houri
- RE: [Speermint] draft-houri-speermint-rtc-provisi… Jean-Francois Mule