IETF Logo Mail Archive

Re: [Netconf] 4741bis -- :url capability issues

Andy Bierman <andyb@iwl.com> Sat, 01 May 2010 01:41 UTC

Return-Path: <andyb@iwl.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D8A3A6912 for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 18:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.179
X-Spam-Level:
X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKRkAFUcFdjv for <netconf@core3.amsl.com>; Fri, 30 Apr 2010 18:41:41 -0700 (PDT)
Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id 897BA3A67EB for <netconf@ietf.org>; Fri, 30 Apr 2010 18:41:41 -0700 (PDT)
Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 70222303C2; Fri, 30 Apr 2010 21:41:27 -0400 (EDT)
Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3F85E30032; Fri, 30 Apr 2010 21:41:27 -0400 (EDT)
Message-ID: <4BDB86C8.6030907@iwl.com>
Date: Fri, 30 Apr 2010 18:41:28 -0700
From: Andy Bierman <andyb@iwl.com>
Organization: Interworking Labs, Inc.
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4BDA3FA5.4020306@iwl.com> <20100430.123559.164315822.mbj@tail-f.com>
In-Reply-To: <20100430.123559.164315822.mbj@tail-f.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] 4741bis -- :url capability issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: andyb@iwl.com
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 May 2010 01:41:42 -0000

Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman <andyb@iwl.com> wrote:
>   
> ....
>   
>>      - the path-spec represents a conceptual file-system in 
>>        the server, or the real file-system.
>>     
>
> An implementation detail IMO.
>
>   


The problem is that way too much of the :url capability
is left as an implementation detail.

There is no way for a client/operator to know from
the standard:
   - what file restrictions are enforced by the server
   - what URL files even exist (the monitoring module
     only supports candidate, running, and startup).

We usually try to announce server capabilities in
the protocol instead of forcing users to call
tech-support, or fish through WEB docs to find out
the same information.

Seems like it would be useful to know what local <url>
database files are available at any given time.
I thought this was supported in the monitoring draft.
I guess locks do not apply, so the existing <database>
element is not appropriate.


Andy

v2.23.0 | Report a Bug | By Email