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
- Proposed text for xyzValidIntervals/xyzInvalidInt… C. M. Heard/VVNET, Inc.
- Re: Proposed text for xyzValidIntervals/xyzInvali… Rajesh Abbi
- Re: Proposed text for xyzValidIntervals/xyzInvali… C. M. Heard/VVNET, Inc.
- Re: Proposed text for xyzValidIntervals/xyzInvali… Gary Hanson
- Re: Proposed text for xyzValidIntervals/xyzInvali… C. M. Heard/VVNET, Inc.