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

"George, Wes" <wesley.george@twcable.com> Wed, 22 April 2015 21:04 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7A31A892E for <idr@ietfa.amsl.com>; Wed, 22 Apr 2015 14:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level:
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 9L-5RsQ6DKr6 for <idr@ietfa.amsl.com>; Wed, 22 Apr 2015 14:04:07 -0700 (PDT)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB061A891B for <idr@ietf.org>; Wed, 22 Apr 2015 14:04:01 -0700 (PDT)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,626,1422939600"; d="scan'208,217";a="241742787"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Apr 2015 16:49:35 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 22 Apr 2015 17:04:00 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "amante@apple.com" <amante@apple.com>
Date: Wed, 22 Apr 2015 17:03:59 -0400
Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
Thread-Index: AdB9P9rR7TKGavUqTfep9b5hlZBVZA==
Message-ID: <D15D82B6.4E6AB%wesley.george@twcable.com>
References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> <D14DB16F.A4767%aretana@cisco.com> <D15C183E.4E361%wesley.george@twcable.com> <D15C10F1.A9B95%aretana@cisco.com>
In-Reply-To: <D15C10F1.A9B95%aretana@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.9.150325
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D15D82B64E6ABwesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/S2QM9ctoZy_z9IRUusbgkqjhu1k>
Cc: Susan Hares <shares@ndzh.com>, idr wg <idr@ietf.org>
Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 22 Apr 2015 21:04:08 -0000

From: "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>>
Date: Tuesday, April 21, 2015 at 4:39 PM
To: "George, Wes" <wesley.george@twcable.com<mailto:wesley.george@twcable.com>>, "amante@apple.com<mailto:amante@apple.com>" <amante@apple.com<mailto:amante@apple.com>>
Cc: "John G. Scudder" <jgs@juniper.net<mailto:jgs@juniper.net>>, Idr <idr@ietf.org<mailto:idr@ietf.org>>, Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Subject: Re: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105

On 4/21/15, 1:26 PM, "George, Wes" <wesley.george@twcable.com<mailto:wesley.george@twcable.com>> 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.


WG] I thought that was the right interpretation too, but enough folks who have been at this far longer than I told me otherwise. Have a look at this thread: https://mailarchive.ietf.org/arch/search/?q=errata+rfc4659
I was never able to get a solid pointer to BCP or normative text or even RFC Editor policy to support either interpretation of what "updates" actually means in the metadata so I now have no opinion on the matter and will go with your guidance, just thought you'd want the background of what I was referring to above.

Thanks
Wes


________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.