RE: "Deprecate"

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 29 August 2013 15:16 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927E311E8123 for <ietf@ietfa.amsl.com>; Thu, 29 Aug 2013 08:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeZ+hp3CeAXk for <ietf@ietfa.amsl.com>; Thu, 29 Aug 2013 08:16:07 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5195711E811B for <ietf@ietf.org>; Thu, 29 Aug 2013 08:16:02 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7TFDnvq005704; Thu, 29 Aug 2013 16:13:49 +0100
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [10.12.10.176]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7TFDn3j005695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 16:13:49 +0100
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7TFDmIk023736; Thu, 29 Aug 2013 16:13:48 +0100
Received: from 950129200 (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7TFDkBj023703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Aug 2013 16:13:47 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Michelle Cotton' <michelle.cotton@icann.org>, "'Dearlove, Christopher (UK)'" <chris.dearlove@baesystems.com>, "'t.p.'" <daedulus@btconnect.com>, 'ietf' <ietf@ietf.org>
References: <B31EEDDDB8ED7E4A93FDF12A4EECD30D3DBD0A61@GLKXM0002V.GREENLNK.net> <CE44ADE0.E6DD3%michelle.cotton@icann.org>
In-Reply-To: <CE44ADE0.E6DD3%michelle.cotton@icann.org>
Subject: RE: "Deprecate"
Date: Thu, 29 Aug 2013 16:13:46 +0100
Message-ID: <077801cea4ca$5ca1cde0$15e569a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFjVHWDZsFWMy4k7oWKjNkNomQ0AJqC66Zw
Content-Language: en-gb
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 15:16:11 -0000

That would be great.

Should 4020bis have a gating normative reference on 5226bis?

Adrian

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> Michelle Cotton
> Sent: 29 August 2013 15:53
> To: Dearlove, Christopher (UK); t.p.; ietf
> Subject: Re: "Deprecate"
> 
> We are working on 5226bis right now and have a plans to discuss the term
> in there.
> 
> --Michelle Cotton
> 
> Michelle Cotton
> Manager, IANA Services
> ICANN
> 
> 
> 
> On 8/29/13 5:22 AM, "Dearlove, Christopher (UK)"
> <chris.dearlove@baesystems.com> wrote:
> 
> >It's definitely an ISO term, I see it used for features of C++.
> >
> >There's then discussion even there of what it means. It is, I think,
> >meant to be used for "we don't think you should use this, there's
> >something better, and this is a warning that it may get removed in a
> >future version". In the case of computer languages there is an additional
> >possibility of "your compiler may emit a warning if you persist in using
> >it".
> >
> >But the only major feature (export) removed in the last C++ version went
> >straight from "part of the standard, but only one compiler ever
> >implemented it, and thus found out it was a bad realisation of an idea"
> >to removed, with no intermediate deprecated stage. And other features
> >just hang around deprecated. So it really doesn't guarantee anything in
> >that instance, neither than if deprecated will go, not if not deprecated
> >won't go.
> >
> >--
> >Christopher Dearlove
> >Senior Principal Engineer, Communications Group
> >Communications, Networks and Image Analysis Capability
> >BAE Systems Advanced Technology Centre
> >West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> >Tel: +44 1245 242194 |  Fax: +44 1245 242124
> >chris.dearlove@baesystems.com | http://www.baesystems.com
> >
> >BAE Systems (Operations) Limited
> >Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> >Centre, Farnborough, Hants, GU14 6YU, UK
> >Registered in England & Wales No: 1996687
> >
> >
> >-----Original Message-----
> >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> >t.p.
> >Sent: 29 August 2013 12:56
> >To: ietf
> >Subject: "Deprecate"
> >
> >----------------------! WARNING ! ----------------------
> >This message originates from outside our organisation,
> >either from an external partner or from the internet.
> >Keep this in mind if you answer this message.
> >Follow the 'Report Suspicious Emails' link on IT matters
> >for instructions on reporting suspicious email messages.
> >--------------------------------------------------------
> >
> >I recently saw 'deprecate' used in an IANA Considerations and turned to
> >"IANA Considerations" [RFC5226] to see how it was defined only to find
> >no mention of it there.  I am used to the term from SMI, as quoted
> >below, but that seems not quite right, in that a deprecated IANA entry
> >never disappears, as in
> >http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
> number
> >s-5
> >
> >Are there other, perhaps better definitions of the term 'deprecated' in
> >use outside SMI (and yes, I know about praying nuns!)?
> >
> >Tom Petch
> >
> >----- Original Message -----
> >From: "Fred Baker (fred)" <fred@cisco.com>
> >To: "IPv6 Maintanence" <ipv6@ietf.org>
> >Sent: Monday, July 29, 2013 3:32 PM
> >Subject: "Deprecate"
> >
> >
> >> At the mike a moment ago, I referred to an existing formal definition
> >of "deprecate". For the record, the reference is to RFC 1158, which
> >reads:
> >>
> >> 3.1.  Deprecated Objects
> >>
> >>    In order to better prepare implementors for future changes in the
> >>    MIB, a new term "deprecated" may be used when describing an object.
> >>    A deprecated object in the MIB is one which must be supported, but
> >>    one which will most likely be removed from the next version of the
> >>    MIB (e.g., MIB-III).
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
> >
> >
> >*************************************************************
> *******
> >This email and any attachments are confidential to the intended
> >recipient and may also be privileged. If you are not the intended
> >recipient please delete it from your system and notify the sender.
> >You should not copy it or use it for any purpose nor disclose or
> >distribute its contents to any other person.
> >*************************************************************
> *******
> >