Re: Proposed text for xyzValidIntervals/xyzInvalidIntervals

"C. M. Heard/VVNET, Inc." <heard@vvnet.com> Fri, 12 June 1998 23:01 UTC

Delivery-Date: Fri, 12 Jun 1998 19:01:41 -0400
Return-Path: heard@vvnet.com
Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA26813 for <ietf-archive@ietf.org>; Fri, 12 Jun 1998 19:01:41 -0400 (EDT)
Received: from mailgate-rtp-1.cisco.com (mailgate-rtp-1.cisco.com [171.69.160.46]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA26990 for <ietf-archive@cnri.reston.va.us>; Fri, 12 Jun 1998 19:04:02 -0400 (EDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by mailgate-rtp-1.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id SAA15447 for <trunk-mib@external.cisco.com>; Fri, 12 Jun 1998 18:54:04 -0400 (EDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id PAA26807 for <trunk-mib@external.cisco.com>; Fri, 12 Jun 1998 15:54:02 -0700 (PDT)
Received: from shell16.ba.best.com(206.184.139.148) by proxy1.cisco.com via smap (V2.0) id xma026802; Fri, 12 Jun 98 22:53:59 GMT
X-SMAP-Received-From: outside
Received: from localhost (heard@localhost) by shell16.ba.best.com (8.8.8/8.8.BEST) with SMTP id PAA11090; Fri, 12 Jun 1998 15:51:13 -0700 (PDT)
X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs
Date: Fri, 12 Jun 1998 15:51:13 -0700
From: "C. M. Heard/VVNET, Inc." <heard@vvnet.com>
X-Sender: heard@shell16.ba.best.com
To: atommib@thumper.bellcore.com, trunk-mib@external.cisco.com
Subject: Re: Proposed text for xyzValidIntervals/xyzInvalidIntervals
In-Reply-To: <Pine.SUN.3.96.980612135006.5494B-100000@skeeter>
Message-ID: <Pine.BSF.3.96.980612152823.6911B-100000@shell16.ba.best.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"

On Fri, 12 Jun 1998, Gary Hanson wrote:
[ ... ]
> Note that xyzValidIntervals up through RFC 1406, RFC 1407, and RFC
> 1595 have never described proxy cases.  If the new text added in the
> current drafts reflects fielded implementations, then it would still
> be possible to change the definitions once more provided:
> - (a) you can convince the implementors of existing fielded
>       implementations to agree to the change (if you can identify
>       who these implementors are)
> - (b) you can convince the IESG and WG chairmen to allow the
>       changes, in the best interests of future network management

I was trying vary hard to avoid that!

> If the new text only reflects SOME of the fielded implementations,
> and if others match your modified interpretation, you have a better
> case still (albeit one that would likely be considered late in
> coming :-).

Let me make clear (if it's not already) that the _intent_ behind my
proposals was just to say more clearly what the current drafts were
intended to say.

> As you know, the xyzInvalidIntervals are likely to be less ingrained
> in fielded implementations, since they are new in the current
> drafts.  For those objects, at least, there would not be any issue
> with having to deprecate them, since they don't "officially" exist
> yet until the RFC is published (at least based on my interpretation
> of how these things evolve).

I really hope that won't be necessary.

> Gary

Mike
--
C. M. Heard/VVNET, Inc.
heard@vvnet.com