Subject: [Rserpool] requirements status

From: "Lyndon Ong" <[email-masked]>
Date: Wed, 11 Apr 2001 09:04:03 -0700

Folks,

Based on the comments so far, I see no reason to postpone the Last Call on the requirements document.  Unless someone sees a major problem, I propose that we start WG Last Call on the requirements beginning next Monday.

Cheers,

Lyndon

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: Michael Tüxen <[email-masked]>
Date: Wed, 11 Apr 2001 20:08:18 +0200

Dear all,
I think that is a good idea.
Best regards
Michael

-- 
e-mail: [email-masked]

On Wed, Apr 11, 2001, Lyndon Ong <[email-masked]> wrote:

>Folks,
>
>Based on the comments so far, I see no reason to postpone the Last Call
>on the requirements document.  Unless someone sees a major problem, I
>propose that we start WG Last Call on the requirements beginning next Monday.
>
>Cheers,
>
>Lyndon
>
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Apr 2001 09:55:00 -0700

[Catching up from vacation]

> propose that we start WG Last Call on the requirements beginning next

Lyndon,

To be frank, I am having a real problem with the document split already. I
want to see a good architectural fit between this mechanism, DNS, and
other Internet mechanisms.  I can't get a feel for that right now because
we don't have the document that explains what we need that DNS don't got. 
There's a lot of text on this mailing list that has some good indicators,
but that's not in Michael's draft.  

Don't get me wrong, by the way.  I *LIKE* the idea that the solution
discussion was moved out of the draft, and I think his requirements draft
is useful.  However, it too needs more work.  For instance, in section 2.3
I'd rather simply the multicast discussion to something like "the
mechanism must operate across intradomain multicast boundaries", since I
believe it IS reasonable at this day and age to operate a PIM sparse-mode
network in a reliable way.  It's the interdomain part that people have
problems with.

Furthermore, 2.4 needs to be reconsidered as well.  Because we are
offering a network service that is not really present today there is no
perfect bridge between any existing mechanism, with the possible exception
of IP anycast.  Is this really the direction you want to go?  Now I think
2.10 pretty much says what I'm saying, so the text needs to be clarified.

In section 2.5, we are bounding the problem, but perhaps to the point
where normal DNS would do the job.  See Bernard's previous EMails.

Regards,
--
Eliot Lear
[email-masked]