IETF Logo Mail Archive

Re: issue 8: final text

Yakov Rekhter <yakov@juniper.net> Thu, 17 October 2002 23:32 UTC

Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29515 for <idr-archive@ietf.org>; Thu, 17 Oct 2002 19:32:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 157A69121C; Thu, 17 Oct 2002 19:34:04 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D773A912DD; Thu, 17 Oct 2002 19:34:03 -0400 (EDT)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B12129121C for <idr@trapdoor.merit.edu>; Thu, 17 Oct 2002 19:34:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 941855DDE1; Thu, 17 Oct 2002 19:34:02 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 360445DDC8 for <idr@merit.edu>; Thu, 17 Oct 2002 19:34:02 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9HNXtm51033; Thu, 17 Oct 2002 16:33:55 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-Id: <200210172333.g9HNXtm51033@merlot.juniper.net>
To: Jeffrey Haas <jhaas@nexthop.com>
Cc: andrewl@xix-w.bengi.exodus.net, Yakov Rekhter <yakov@juniper.net>, idr@merit.edu
Subject: Re: issue 8: final text
In-Reply-To: Your message of "Thu, 17 Oct 2002 17:43:15 EDT." <20021017174315.X19953@nexthop.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <73769.1034897635.1@juniper.net>
Date: Thu, 17 Oct 2002 16:33:55 -0700
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-idr@merit.edu
Precedence: bulk

Jeff,

> On Thu, Oct 17, 2002 at 02:35:19PM -0700, andrewl@xix-w.bengi.exodus.net wrot
e:
> > Wouldn't this be the same as implementing the timers seperately with the
> > same values?  I would argue that it a vendor wishes to do so they may,
> > but it doesn't affect interoperabilty or the text Yakov posted.  The
> > different values in the text are only "suggested defaults" so there is
> > room of implementations to choose different default values.
> 
> The main reason I mentioned this was the fact that the lack of
> implemented complex path aggregation was reason enough to call for
> its removal from the spec.  If we're going to have this requirement,
> this is another spot where its at issue.
> 
> In any case, I don't disagree with your assessment. :-)

So, with this in mind, let's assume that we have a consensus
and close the issue.

Yakov.

v2.46.0 | Report a Bug | By Email | System Status