IETF Logo Mail Archive

Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

Randy Bush <randy@psg.com> Fri, 26 May 2017 02:39 UTC

Return-Path: <randy@psg.com>
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 C8E8A1293F2; Thu, 25 May 2017 19:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.502
X-Spam-Level:
X-Spam-Status: No, score=-5.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 uUg23mg0gvTx; Thu, 25 May 2017 19:39:55 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACBFB128796; Thu, 25 May 2017 19:39:55 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1dE5AN-0003u4-9Q; Fri, 26 May 2017 02:39:51 +0000
Date: Fri, 26 May 2017 11:39:48 +0900
Message-ID: <m21srcmjd7.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Lou Berger <lberger@labn.net>
Cc: John E Drake <jdrake@juniper.net>, Eric Rosen <erosen@juniper.net>, John Scudder <jgs@juniper.net>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
In-Reply-To: <6c89a60e-e205-223e-1823-c4b8499f1b2e@labn.net>
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <c735e3fe-1b0e-23a6-78bf-7e773e605a52@juniper.net> <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net> <CO2PR05MB618B4D4BC607325D25D29C0C7FF0@CO2PR05MB618.namprd05.prod.outlook.com> <6c89a60e-e205-223e-1823-c4b8499f1b2e@labn.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-8859-7"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5RM18DO8UOULGJBfmq3H1-bP6fc>
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 26 May 2017 02:39:57 -0000

> considering the impact of deprecating an RFC on other RFCs seems to me
> to be a reasonable thing to cover in the rfc doing the deprecating...

the transitive closure, while bounded, could be quite large

>> Is it really the responsibility of  a RFC which obsoletes a another
>> RFC to explain how every RFC referencing the obsoleted RFC is to be
>> updated?  I think it’s a much better idea to  update each of these
>> RFCs individually.  So, as Eric suggests, I think an update to RFC
>> 5566 is in order.

this makes more sense

randy

v2.23.0 | Report a Bug | By Email