Re: [MIB-DOCTORS] [OPSAWG] [OPS-DIR] http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes -10.txtandRFC4560

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 14 August 2008 17:43 UTC

Return-Path: <mib-doctors-bounces@ietf.org>
X-Original-To: mib-doctors-archive@optimus.ietf.org
Delivered-To: ietfarch-mib-doctors-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E6D3A69DF; Thu, 14 Aug 2008 10:43:24 -0700 (PDT)
X-Original-To: mib-doctors@core3.amsl.com
Delivered-To: mib-doctors@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C753A68A2; Thu, 14 Aug 2008 10:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 9ZhD9dhg8Lil; Thu, 14 Aug 2008 10:43:21 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 63BF63A68A0; Thu, 14 Aug 2008 10:43:21 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DE1DC00F7; Thu, 14 Aug 2008 19:43:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ycGr0LohaqXv; Thu, 14 Aug 2008 19:43:11 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AFF5C00F9; Thu, 14 Aug 2008 19:43:11 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 80A8768B3BB; Thu, 14 Aug 2008 19:43:10 +0200 (CEST)
Date: Thu, 14 Aug 2008 19:43:10 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Message-ID: <20080814174310.GC1637@elstar.local>
Mail-Followup-To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, ops-dir@ietf.org, opsawg@ietf.org
References: <003701c8fd6c$17cf0e40$6801a8c0@oemcomputer> <EDC652A26FB23C4EB6384A4584434A04ECC5DF@307622ANEX5.global.avaya.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04ECC5DF@307622ANEX5.global.avaya.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, ops-dir@ietf.org, opsawg@ietf.org
Subject: Re: [MIB-DOCTORS] [OPSAWG] [OPS-DIR] http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes -10.txtandRFC4560
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mib-doctors>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mib-doctors-bounces@ietf.org
Errors-To: mib-doctors-bounces@ietf.org

On Thu, Aug 14, 2008 at 02:29:18PM +0200, Romascanu, Dan (Dan) wrote:
 
> Randy,
> 
> Can you explain what other reading can be given from the following
> phrase in section 3 of RFC 2579? 
> 
> 'Further, all names used for the textual conventions
>    defined in all "standard" information modules shall be unique.'
> 
> IMO the fact that IMPORTS statements referencing these descriptors must
> use the actual module name does not contradict in any way the
> requirement for uniqueness of TC descriptor names in SMIv2, but rather
> is just a linkage necessity derived from the fact that there is no
> single module that includes all standard TCs. 

I believe the sentence in question is a policy rule and has no sound
technical basis. If the rule does have a technical basis, then the
SMIv2 has (i) a technical defect since TC name collisions can happen
in non-"standard" modules and (ii) there is no mechanism in place to
actually guarantee unique TC names in all "standard" information
modules. (And I am not asking the question what "standard" in quotes
means. ;-)

In the future and the concrete case of YANG, we should try hard to
properly separate policy from mechanisms.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors