Re: [Speermint] Review of draft-houri-speermint-rtc-provisioning-reqs-00.txt
Avshalom Houri <AVSHALOM@il.ibm.com> Mon, 18 September 2006 01:37 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP84w-0004mS-Pt; Sun, 17 Sep 2006 21:37:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP84v-0004lj-74 for speermint@ietf.org; Sun, 17 Sep 2006 21:37:45 -0400
Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP84s-0007BB-Ce for speermint@ietf.org; Sun, 17 Sep 2006 21:37:45 -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 k8I1beSU084418 for <speermint@ietf.org>; Mon, 18 Sep 2006 01:37:40 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 k8I1gNXZ3018864 for <speermint@ietf.org>; Mon, 18 Sep 2006 03:42:23 +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 k8I1be1m005166 for <speermint@ietf.org>; Mon, 18 Sep 2006 03:37:40 +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 k8I1beQr005163 for <speermint@ietf.org>; Mon, 18 Sep 2006 03:37:40 +0200
In-Reply-To: <4500111C.4060400@gmx.net>
To: speermint@ietf.org
MIME-Version: 1.0
Subject: Re: [Speermint] Review of 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: <OF9C71EB74.F923B5B9-ONC22571ED.0008A9B7-C22571ED.0008F129@il.ibm.com>
Date: Mon, 18 Sep 2006 04:42:21 +0300
X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 18/09/2006 04:42:22, Serialize complete at 18/09/2006 04:42:22
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d
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="===============0360210416=="
Errors-To: speermint-bounces@ietf.org
Hannes, Thanks for the detailed comments. It is apparent that the document has to be rewritten and I will refer to them in the next version of the document. I am not still sure if it should be part of the general requirements document or a use case document for presence and IM. --Avshalom Hannes Tschofenig <Hannes.Tschofenig@gmx.net> 07/09/2006 15:31 To speermint@ietf.org cc Subject [Speermint] Review of draft-houri-speermint-rtc-provisioning-reqs-00.txt Hi all, I went through draft-houri-speermint-rtc-provisioning-reqs-00.txt and here are some high level comments: * I was a bit lost with the proposed terminology. I am not so sure whether it is inline with the terms used in the terminology document. Let us take a look at the following figure: +----+ | LF | ------- +----+ ------- / \ | | / \ | LF---+ +---LF | | | | | | PF-----------PF | | | | | | SIP SF-----------SF SIP | | Service | | Service | |Provider MF---------MF Provider| | I | | R | | | | | | | | | \ / \ / ------- ------- This figure is taken from the architecture document. When you talk about provisioning then I suspect you talk about the communication between the SF and the MF. Right? Are you focused on (a) the communication between the SF and the MF belonging to the same SIP Service Provider OR (b) the communication between components interacting between Service Provider I and R from the figure above (e.g., the PF(I) and PF(R) talking to each other)? * The requirements need to use RFC 2119 language and should to be motivated. Take a look at the ECRIT requirements draft to see what I mean. Here is the document: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-12.txt For example, I don't understand the following requirement: CORE-REQ-003: It should be possible to provide the FQDN of the edge proxies of the other community. What is the motivation for the requirement? * CORE-REQ-004 CORE-REQ-004: It should be possible to provide necessary details regarding firewall and NAT that will enable easier connection of other communities to the community Are you talking about policies or the process of allowing the flow to go through the firewall/NAT? For example, you might want to trigger an interaction between the SF and the MF for this purpose. If firewall traversal is in your scope why is QoS outside the scope. They are conceptually very similar: Some actions perform on a specific traffic pattern. To make things a bit more complicated: Do you consider both path-coupled and path-decoupled NAT/Firewall (and eventually QoS) signaling? * CORE-REQ-008 CORE-REQ-008: It should be possible to provide the possible encryption methods that are expected by the community. Encryption methods for securing signaling traffic I suspect. Let us assume that a key management like IKE(IKEv2) or the TLS handshake protocol is used. These protocol provide ciphersuite / algorithm negotiation. Would this meet your needs or do you have something else in mind? * CORE-REQ-010 CORE-REQ-010: It should be possible to provide the maximum number of allowed concurrent connection that are acceptable by the community. What type of connection? * Some requirements in Section 4 sound like "Please tell me what SIP extensions are implemented by a specific service provider." Is my understanding correct? * References have to be split into normative & informative requirements. You only list RFC 2119 (although you do not use it); this would be a normative reference. Note that the RFC 2119 language refers to the implementation of a protocol that will be later developed (I guess). The text in the security consideration section should also refer to the protocol that might be developed in the future. Hence, requirement CORE-REQ-002 fits very well in the security consideration section. Ciao Hannes _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint
_______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint
- [Speermint] Review of draft-houri-speermint-rtc-p… Hannes Tschofenig
- Re: [Speermint] Review of draft-houri-speermint-r… Avshalom Houri