Subject: Re: [Rserpool] WG Last Call on Rserpool Requirements

From: "Lyndon Ong" <[email-masked]>
Date: Fri, 20 Apr 2001 17:14:12 -0700

I think that we should be focusing on (1) - more precise requirements at this point.  I agree that there are requirements stated in the draft that need some further explanation or justification, and we should be trying to propose such further text during Last Call.

Focusing on (2) - why existing mechanisms don't work - is a little putting the cart before the horse, but it's worth thinking more about to see whether there are some requirements that are missing or could be stated more clearly in the draft (however, we can't keep doing comparisons forever).  

As a suggestion, maybe we could put something in about the solution trading off scalability vs. speed of failure detection and compensation.  That seems like one major distinction between what we're aiming for and some existing mechanisms that aim to be more globally scalable.

BTW, not being a DNS expert, I'd be happy if someone gave a quick explanation of how some DNS features are actually being used.  Bernard mentioned NOTIFY/IXFR, but as I read the RFCs, these seem to be mechanisms for one name server to update the records in another name server.  There's also DNS Dynamic UPDATE, but again it's not clear if this is ever used from an application server to update the records at a name server.

Cheers,

Lyndon 
--

On Fri, 20 Apr 2001 16:13:27   Eliot Lear wrote:
>Qiaobing,
>
>Here's an example.
>
>Section 2.7 does not give sufficient detail to understand what the timing
>requirement is.  What's fast?  By understanding why DNS doesn't meet that
>requirement perhaps we can articulate it better.  What 2.7 DOES talk about
>is the number of pool elements, but that's insufficient to understand what
>the timing requirements are.  What is the property that we need from a new
>mechanism that the existing mechanism lacks?  That's what I come back to.  
>
>There are a number of requirements that are listed in the draft that have
>no stated reason for their being there.  Now there was some discussion,
>but not in the document.  For instance, see section 2.10.  Why are pool
>handles, as opposed to names, a requirement?  Why are we scoping these
>things the way we are in the requirements document?
>
>So I guess I want two things:
>
>1.  More precise requirements
>
>2.  A good argument why existing mechanisms don't work.
>
>I think that if you do either sufficiently well you get the other for
>free.  Right now I'm not comfortable with either.
>--
>Eliot Lear
>[email-masked]
>
>
>Qiaobing Xie wrote:
>> 
>> Eliot,
>> 
>> I am completely lost here. You are talking about solutions but I think
>> we are still working on the requirements.
>> 
>> IMO, we need to first clearly lay out what Rserpool requirements are.
>> After that, if it turns out that some existing technology (e.g., DNS,
>> DNS+, etc.) meets all the identified requirements, it would be wonderful
>> - we won't need to invent another protocol.
>> 
>> But at this point, I agree with John, requirements are requirements and
>> they don't change no matter whether DNS is an adequate solution or not.
>> 
>> regards,
>> -Qiaobing
>
>_______________________________________________
>rserpool mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/rserpool
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Apr 2001 17:55:30 -0700

Lyndon,

I think you and I are pretty close.  As you allude, this is an iterative
process, but let's not iterate too many times before kicking the
requirements out the door.  On the other hand, let's get the requirements
right.

FYI there are now several mechanisms to do dynamic update, the latest of
which is found in RFC 3007.  I suggest people review it.
--
Eliot Lear
[email-masked]