Re: bgp4-17 Cease subcode

Alex Zinin <azinin@nexsi.com> Thu, 17 January 2002 02:54 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA24785 for <idr-archive@nic.merit.edu>; Wed, 16 Jan 2002 21:54:01 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 291BE912C5; Wed, 16 Jan 2002 21:53:22 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0CB9912C6; Wed, 16 Jan 2002 21:53:21 -0500 (EST)
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 092D6912C5 for <idr@trapdoor.merit.edu>; Wed, 16 Jan 2002 21:53:21 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E1B365DDB7; Wed, 16 Jan 2002 21:53:20 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id B6D045DD8E for <idr@merit.edu>; Wed, 16 Jan 2002 21:53:20 -0500 (EST)
Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id B6F5D3F70; Wed, 16 Jan 2002 18:56:08 -0800 (PST)
Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA13422; Wed, 16 Jan 2002 18:52:26 -0800
Date: Wed, 16 Jan 2002 18:52:26 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <86212899232.20020116185226@nexsi.com>
To: Randy Bush <randy@psg.com>
Cc: idr@merit.edu
Subject: Re: bgp4-17 Cease subcode
In-Reply-To: <E16R19U-0005pQ-00@roam.psg.com>
References: <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <114185201786.20020116111047@nexsi.com> <E16R19U-0005pQ-00@roam.psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

Randy,

> if the introduction of idlehold makes life clearer for implementors,

This is what I'm not sure about...

Controlling [existing] Start event generation that lets the FSM
out of the [existing] Idle state seems easier than introducing,
documenting, coding, and checking of a new one...

Alex.

> yet
> it changes the fsm but not in incompatible ways (i.e. old would interop
> with new and wire looks the same, as jeff asserts.  maybe sufficient
> sushi could convince an area director not to ding the progress status of
> the document.

> randy