Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105

"Alvaro Retana (aretana)" <> Tue, 21 April 2015 20:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F12681B2B14 for <>; Tue, 21 Apr 2015 13:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Bt-dVM7IuaV for <>; Tue, 21 Apr 2015 13:39:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 627B91B2B0F for <>; Tue, 21 Apr 2015 13:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4069; q=dns/txt; s=iport; t=1429648754; x=1430858354; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ATUXlPBobpN+iH7bEWcKAz/UQrd9z0rr9QBElzPCywk=; b=O7uXQKcbqBZR1XAtXUPAVC9/V5CJKNcMx8m3asTKdSBdre4fgC4zTEO5 jP0ncAr7YZrVCiVkWeeCdH2QNyprWcGZJGheDavjRvGKLPR1sQfJgUJaz AGkTxgC0ivXIsr2U+OYshRu6u5WMEdF8tAYkE+NX+WBGoTRT5+1d2gmqx k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,618,1422921600"; d="scan'208,217";a="413679532"
Received: from ([]) by with ESMTP; 21 Apr 2015 20:39:13 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t3LKdDv0027085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Apr 2015 20:39:13 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 21 Apr 2015 15:39:13 -0500
From: "Alvaro Retana (aretana)" <>
To: "George, Wes" <>, "" <>
Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
Thread-Index: AdBzlDcUkdJmp22uTqShwxbVd0A/MgCn6C+AAZfGYoD//6/GgA==
Date: Tue, 21 Apr 2015 20:39:12 +0000
Message-ID: <>
References: <003f01d07394$9b5f1c00$d21d5400$> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D15C10F1A9B95aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: Susan Hares <>, idr wg <>
Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Apr 2015 20:39:19 -0000

On 4/21/15, 1:26 PM, "George, Wes" <<>> wrote:



This document should be marked as updating rfc4271 because of the processing of the UPDATEs (section 3.3).

WG] Happy to make that change, but the reason that it wasn't there is that this isn't mandatory to implement. It's not globally changing the behavior of UPDATEs, but rather documenting how they change when this specific optional feature set is invoked. Someone recently gave me guidance on a different draft that it isn't always appropriate to have a draft update an old RFC if the new thing isn't mandatory to implement as a part of the old RFC I.e. A formal update in the metadata means that the two (or more) RFCs together represent a complete BGP implementation, while only implementing the original RFC (the one being updated) would be an incomplete implementation. I don't know if there is an official stance on this as far as the RFC series is concerned, so I'm open to do it either way, need guidance on how to proceed.

I interpret it the other way: when implementing this optional mechanisms the base RFC is updated..and only when the optional mechanisms are implemented.

Let’s go with the update marking and we can talk about it in the IESG if it comes up.