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

From: [email-masked]
Date: Fri, 20 Apr 2001 12:26:44 +0300

Hi Eliot,

> Let's be clear: the reason one has a requirements document is 
> to engineer to them.  Without the other document the requirements 
> document lacks sufficient context to engineer a solution.  Another 
> way to put this- we may need to change the requirements document 
> based on what is in the other document.

I cannot parse this.  In my opinion, the requirements will not
change no matter what someone has to say about DNS (for example).
If the requirement for Reliable Server Pooling is 'X', then it
is X.  I think the combination of the Requirements document plus
the Protocol Discussion document will point to the solution.

best regards,
John

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Apr 2001 10:08:54 -0700

> the Protocol Discussion document will point to the solution.

Consider the following subdomain:

$ORIGIN MYPHONECOMPANY.COM.
SERVERPOOL	IN	NS	POOL-SERVER1.MYPHONECOMPANY.COM.
		IN	NS	POOL-SERVER2.MYPHONECOMPANY.COM.
		IN	SOA	MAILADDR.MYPHONECOMPANY.COM (
				10111; serial
				10; secondary refresh
				60; secondary retry
				120; secondary expire
				3 ) default TTL

So, if I put name servers behind content switches and use anycast
addresses for POOL-SERVER1.MYPHONECOMPANY.COM, what problem is NOT being
solved?  What is it about this solution that doesn't work?  [the 'why are
we here' question] Is THAT captured in the requirements document?  I can't
tell because we've split these documents.
--
Eliot Lear
[email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 20 Apr 2001 16:23:40 -0500

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Apr 2001 16:13:27 -0700

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]