Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

Job Snijders <job@ntt.net> Tue, 01 November 2016 18:00 UTC

Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F521294DA for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 11:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level:
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGCiIsysFVRp for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 11:00:55 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B831129413 for <idr@ietf.org>; Tue, 1 Nov 2016 11:00:55 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1c1dMh-0007n5-8W (job@us.ntt.net); Tue, 01 Nov 2016 18:00:52 +0000
Date: Tue, 1 Nov 2016 19:00:47 +0100
From: Job Snijders <job@ntt.net>
To: "t.petch" <ietfc@btconnect.com>
Message-ID: <20161101180047.GN966@Vurt.local>
References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <F744170E-172A-40E6-98EF-2A7BF6BF9DE1@juniper.net> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Kr69KFEMjiSwH0qPJfFVd2zXjCM>
Cc: IETF IDR Working Group <idr@ietf.org>
Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2016 18:00:57 -0000

On Tue, Nov 01, 2016 at 05:44:27PM +0000, t.petch wrote:
> We all know what deprecate means which, based on recent discussions of
> other topics on this list, means we are using many divergent ones in
> our assessment of this I-D.
> 
> 'deprecate' is a technical term in the processes of the IETF.  You
> need to define it, or better, use the existing definition.

Why does it need to be defined? Are you saying that it is unclear what
the existing "deprecated" entries in
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2
mean?

> That definition is in draft-leiba-cotton-iana-5226bis-18 which
> therefore MUST/SHALL be/is REQUIRED to be a Normative Reference, and
> yes, that means waiting for that to become an RFC before this can
> advance; which interaction I see as a necessity.

I am confused, it appears you assign normative value to something that
as of yet is a draft? Why is there a dependency? Can you also point out
which specific section of draft-leiba-cotton-iana-5226bis-18 you are
referring to?

For the working group's overview: I've taken as example:
https://tools.ietf.org/html/rfc6938 . This document does not contain
RFC2119 language.

> Otherwise, we haven't a clue what we are adopting.  Well we have, but it
> is about a dozen different clues.
> 
> Likewise, but not so critical at this stage, having an RFC that starts
> ' This document requests IANA   ..' will look, well, not very
> sensible.  If you believe in what you are doing, then I would like you
> to state it as a fact.  'This memo changes the status of ... in the
> IANA Registry to 'deprecated'

A stylistic comment wrapped around "if you believe in what you are
doing", .. really?

> And what you have at present sits oddly with the IANA Considerations.
> Usually, the latter says
> 'IANA is asked to ...'
> which is edited by the RFC Editor
> 'IANA has ...'
> 
> Yet you have an IANA Considerations of
> 'IANA has  ...
> Back to front, IMHO.

I can update the grammatical tense. No big deal.

Kind regards,

Job