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

From: [email-masked]
Date: Tue, 17 Feb 2004 09:56:34 +0200

Hi all,

Jon Peterson sent these comments on draft-ietf-rserpool-comp-07.  As I 
was updating the document, I ran into some problems & I think some discussions
are needed.

> This document does a nice amount of due diligence in evaluating existing
> solutions for the rserpool problem space. While I'm sure there are others
> that could have been included, this provides a pretty comprehensive look at
> the sorts of protocols out there that should be considered.
> 
> The section on DNS will probably attract the most attention from the IESG. I
> think there are two issues with that section as it stands: first, it does
> not discuss DDDS (RFC3401 passim); second,  it does not discuss EPP
> (draft-ietf-provreg-epp-09). Some sort of comparison with the qualities of
> those protocols is warranted, since they provide some qualities that, say,
> SRV does not. The potential use of URNs for pool handles should also be
> discussed along with DDDS.
> 
> In general, as well, the comparison to DNS seems a little questionable in so
> far as it assumes that there must be one protocol that performs the function
> of name resolution, keepalives, and NS provisioning. In fact, as I commented
> on the rserpool architecture document, those are separable functions with
> radically different properties and associated message exchanges, and very
> credible motivation is required to establish that a single protocol should
> be tooled to perform those functions. I think there are arguments to made
> against the use of the DNS for RSERPOOL, but I don't think it's fair to say
> that 'doesn't provide keepalives' is one of them.
> 
> In the SLP section (beginning of 2.3.3) in particular, the distinction
> between a service-oriented and communication-oriented solution is a little
> obscure to me. But overall I think the analysis here is sound. Same for the
> analyis of L4/L7 switching.

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.

thanks,
John

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: [email-masked]
Date: Tue, 17 Feb 2004 09:56:34 +0200

Hi all,

 

thanks,
John

---

From: Silverton Aron-C1710C <[email-masked]>
Date: Tue, 17 Feb 2004 10:35:11 -0600

[email-masked] <> wrote:
>snip
>    My general feeling is that DDDS will suffer similar problems as
>    DNS, in terms of the lack of dynamicity in DDS.
> 
>    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. 
> 
>    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. 
> 

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.

> John

Aron

> [email-masked] https://www1.ietf.org/mailman/listinfo/rserpool

---

From: [email-masked]
Date: Wed, 18 Feb 2004 11:35:31 +0200

Hi Aron,

> 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.

Agreed.  I think I can just try to clarify the text.
 
> 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.

I think we need to check the documents Jon pointed out &
craft text to cover the issue.

John

---

From: [email-masked]
Date: Wed, 18 Feb 2004 11:35:31 +0200

Hi Aron,

 

John