Re: [irs-discuss] Rough Draft IRS Charter

Russ White <> Mon, 22 October 2012 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D55B321F84FE for <>; Mon, 22 Oct 2012 10:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pok2ny21UEOd for <>; Mon, 22 Oct 2012 10:49:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 730E911E80A4 for <>; Mon, 22 Oct 2012 10:49:51 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1TQM8M-0001zG-UM for; Mon, 22 Oct 2012 10:49:51 -0700
Message-ID: <>
Date: Mon, 22 Oct 2012 13:50:07 -0400
From: Russ White <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
Subject: Re: [irs-discuss] Rough Draft IRS Charter
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Oct 2012 17:49:51 -0000

I think this has already been brought up on the list once before, but
I'd just like to repeat my concerns on it:

Thus, the IRS is a "fast path" that can be used to program routing and
policy state in a router using operational paradigms familiar to
operators of traditional distributed devices. This differs from the
programmatic "slow state" that is commonly a device's configuration
interface because those mechanisms impose many transactional mechanisms
and requirements, that may slow down the interaction.

Describing the CLI or other existing interfaces as the "slow path," and
the proposed as the "fast path," is problematic. First, it implies that
there is a specific path already available into all control plane
devices, and that single path is "too slow," for some meaning of "too
slow." Second, it implies, from the start, that we need new path, rather
than a possible structure around existing paths that we can use to make
sense of the routing system as a whole.

I think 2a needs to be better defined so it doesn't overlap with 2c, or
2c needs to be made a part of 2a in some way (?).