RE: [Rserpool] FW: AD review of draft-ietf-rserpool-comp-07

Silverton Aron-C1710C <Aron.J.Silverton@motorola.com> Tue, 17 February 2004 16:41 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15221 for <rserpool-archive@lists.ietf.org>; Tue, 17 Feb 2004 11:41:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8HM-00020i-P6; Tue, 17 Feb 2004 11:41:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8Gy-0001zu-TK for rserpool@optimus.ietf.org; Tue, 17 Feb 2004 11:40:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15125 for <rserpool@ietf.org>; Tue, 17 Feb 2004 11:40:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8Gx-0003NG-00 for rserpool@ietf.org; Tue, 17 Feb 2004 11:40:36 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8Fe-0003Ey-00 for rserpool@ietf.org; Tue, 17 Feb 2004 11:39:15 -0500
Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1At8FH-0003Bg-00 for rserpool@ietf.org; Tue, 17 Feb 2004 11:38:52 -0500
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1HGcoAH013581 for <rserpool@ietf.org>; Tue, 17 Feb 2004 09:38:51 -0700 (MST)
Received: from il02exm11.corp.mot.com (il02exm11.corp.mot.com [10.0.111.22]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i1HGZEcQ014648 for <rserpool@ietf.org>; Tue, 17 Feb 2004 10:35:25 -0600
Received: by il02exm11 with Internet Mail Service (5.5.2657.2) id <18YS95BS>; Tue, 17 Feb 2004 10:35:20 -0600
Message-ID: <6F8DFFA2C996D711945800065BFC9E4A0389878A@il02exm11>
From: Silverton Aron-C1710C <Aron.J.Silverton@motorola.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, rserpool@ietf.org
Subject: RE: [Rserpool] FW: AD review of draft-ietf-rserpool-comp-07
Date: Tue, 17 Feb 2004 10:35:11 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.2)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: rserpool-admin@ietf.org
Errors-To: rserpool-admin@ietf.org
X-BeenThere: rserpool@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=unsubscribe>
List-Id: Reliable Server Pooling <rserpool.ietf.org>
List-Post: <mailto:rserpool@ietf.org>
List-Help: <mailto:rserpool-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=subscribe>

john.loughney@nokia.com <> wrote:
> Hi all,
> 
>snip
> 
> The main points raised are:
> 
> 1) Discussion of RFC3401, etc.
>    http://www.ietf.org/rfc/rfc3401.txt?number=3401
> 
>    My general feeling is that DDDS will suffer similar problems as
>    DNS, in terms of the lack of dynamicity in DDS.
> 
> 2) Discussion of draft-ietf-provreg-epp-09 is more difficult.
> 
>    http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09
> 
>    EPP looks at some levels like it could provide some solutions, but
>    just in different ways than what has originally been thought of. 
>    I would need some other folks to review EPP and DDS, to see what
> other folks think. 
> 
> 3) Support for URNs.  We have some discussions on namespace issues &
>    identifiers for RserPool.  If we don't want to support URNs, we
>    need good reasons why we think that URNS are not a good idea for
> Rserool. 
> 
> 4) Text about SLP & l4/l7 I can probably fix.

John, according to Jon P's email, the L4/L7 stuff is ". . . I think the analysis here is sound. Same for the analysis of L4/L7 switching."  So I wouldn't waste too many cycles on that unless you feel that there is something that needs to be changed.

As for the other portions, I'm not familiar with them so I will have to read the drafts.  I think that some of the comments that Qiaobing made in the past regarding loosely-coupled approaches of trying to integrate many protocols versus a tightly-coupled protocol (RSERPOOL) will hold here as well.  All the more so if we stress that RSERPOOL is intended for system with some degree of real-time performance constraints.

> 
> thanks,
> John

Aron

> 
> _______________________________________________
> rserpool mailing list
> rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool

_______________________________________________
rserpool mailing list
rserpool@ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool