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

Job Snijders <> Tue, 01 November 2016 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1F521294DA for <>; Tue, 1 Nov 2016 11:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.432
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TGCiIsysFVRp for <>; Tue, 1 Nov 2016 11:00:55 -0700 (PDT)
Received: from ( [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B831129413 for <>; Tue, 1 Nov 2016 11:00:55 -0700 (PDT)
Received: by with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c1dMh-0007n5-8W (; Tue, 01 Nov 2016 18:00:52 +0000
Date: Tue, 1 Nov 2016 19:00:47 +0100
From: Job Snijders <>
To: "t.petch" <>
Message-ID: <20161101180047.GN966@Vurt.local>
References: <> <> <> <> <01c101d23467$9c8b0cc0$>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01c101d23467$9c8b0cc0$>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <>
Cc: IETF IDR Working Group <>
Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

> 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: . 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,