Re: Progressing: draft-farrel-rtg-manageability-requirements-01.txt

Curtis Villamizar <curtis@faster-light.net> Sat, 19 November 2005 15:44 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdUtE-0006Fq-11; Sat, 19 Nov 2005 10:44:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdUtB-0006Fl-LZ for routing-discussion@megatron.ietf.org; Sat, 19 Nov 2005 10:44:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04371 for <routing-discussion@ietf.org>; Sat, 19 Nov 2005 10:43:52 -0500 (EST)
Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdVBD-0005BM-1O for routing-discussion@ietf.org; Sat, 19 Nov 2005 11:03:10 -0500
Received: (qmail 37647 invoked from network); 19 Nov 2005 15:44:14 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 19 Nov 2005 15:44:14 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id jAJFj1N8024109; Sat, 19 Nov 2005 10:45:01 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net)
Message-Id: <200511191545.jAJFj1N8024109@workhorse.faster-light.net>
To: Adrian Farrel <adrian@olddog.co.uk>
In-reply-to: Your message of "Fri, 18 Nov 2005 21:01:33 GMT." <00dd01c5ecf0$045f0750$fb849ed9@Puppy>
Date: Sat, 19 Nov 2005 10:45:01 -0500
From: Curtis Villamizar <curtis@faster-light.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: Bill Fenner <fenner@research.att.com>, zinin@psg.com, Avri Doria <avri@acm.org>, routing-discussion@ietf.org, Loa Andersson <loa@pi.se>
Subject: Re: Progressing: draft-farrel-rtg-manageability-requirements-01.txt
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: curtis@faster-light.net
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
Sender: routing-discussion-bounces@ietf.org
Errors-To: routing-discussion-bounces@ietf.org

In message <00dd01c5ecf0$045f0750$fb849ed9@Puppy>
"Adrian Farrel" writes:
>  
> Attention ADs.
>  
> I wouldn't claim overwhelming support, but I would also note that the
> only issues raised so far were by you at the meeting in Vancouver.
>  
> So where do we go from here?
>  
> We originally positioned this as Informational, but making firm
> requirements.
>  
> My suggestion, in response to your concerns in Vancouver was to keep
> this as Informational, but drop the requirements making the
> Manageability Concerns section advisory.
>  
> The small email exchange on the list, however, is requesting BCP
> status with firm requirements.
>  
> Do you want to give some guidance and enter into a discussion?
>  
> Cheers,
> Adrian


Adrian,

It makes no sense to try to mandate something in an informational
draft.

If you mandated this structure most routing protocols would have to
cite the same link liveness and host liveness protocols and how they
interact plus the mechanisms of the protocol itself.

If there is a set of routing protocol for which management is not
widely enough understood, having a separate informational draft would
be good.  Otherwise to be complete this would be a very big section.

For example, in addition to MIB you missed XML.  Do you cite the DTD
and a sample XLST?  Is there such a things as a common XML DTD across
vendors (I think not)?  If a routing protocol was written prior to the
use of XML for management would that preclude using XML or require a
new iteration of each routing protocol?

I think it is a mistake to put in a "how to run your network" tutorial
in each routing protocol.  So far operations practices have changed
independently of iterations of the routing protocol itself.  Even
implememtation changes such as coupling with link liveness and
neighbor liveness detection occur independently of the routing
protocol itself.  Coupling the routing protocol with management of the
routing protocol by putting it in the same document would be a
mistake.

Curtis

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion