On Tue, Jun 27, 2000 at 04:46:32PM +0200, Niels M�ller wrote:
> Ben Black <[EMAIL PROTECTED]> writes:
>
> > Pending any description of how this draft provides *any*
> > technical benefit (for example, what situations it covers
> > which cannot be accomplished for efficiently and effectively
> > with the RFC2260-based proposal), I am strongly against
> > this draft moving forward.
>
> I'm I bystander here, but as far as I can see, it appears that some
> people like the approach, and really want to try it out. Then it ought
Actually, I am looking for any indication that there is, in fact,
*anyone* who wants to use this approach. So far, all my requests for
an application of this approach which isn't *better* handled with
another, existing method have gone unanswered.
> to be a good thing to have it published so that both people
> implementing it and people shooting it down can have a clear
> description to refer to. After all, we're talking about an
I do not see why an informational RFC is needed just as a point of
reference for a debate. The draft is just fine for that purpose.
An informational RFC in this context should be documentation of
a potential approach offering benefits to the network operator
not offered by other approaches.
So, I once again ask that someone provide a reasonable scenario
in which the approach in the J. Yu draft offers benefits over the
RFC2260/Itojun approach.
Ben
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
