Re: [sidr] [Technical Errata Reported] RFC8206 (7183)

Wes George <wesgeorge@puck.nether.net> Wed, 26 October 2022 20:21 UTC

Return-Path: <wesgeorge@puck.nether.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5343DC14F5E1 for <sidr@ietfa.amsl.com>; Wed, 26 Oct 2022 13:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=puck.nether.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9lfcEmY8Pdr for <sidr@ietfa.amsl.com>; Wed, 26 Oct 2022 13:20:56 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241E2C14E514 for <sidr@ietf.org>; Wed, 26 Oct 2022 13:20:48 -0700 (PDT)
Received: from [IPV6:2600:4040:2e7c:8700:2965:8d4b:3f14:fcf1] (unknown [IPv6:2600:4040:2e7c:8700:2965:8d4b:3f14:fcf1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 2C8B8540213; Wed, 26 Oct 2022 16:20:42 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 puck.nether.net 2C8B8540213
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=puck.nether.net; s=default; t=1666815642; bh=0wCh7F75Oghn27Gks/ZUU/8tlTxD27xuFibSFYejQ5o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=sfnaqDq9C5qZpYqMi1lWyIqe9H5lMQ2CHaB4Ll/Kj7Qw6IDjJ2chnqvFWx8YhzX/F v680Vg9Fb3/0wCgPhJY81duiNT/16OCSxnPwPGSkIETIPT1hqCxRPO92g4B6Avg+YR f3vlM/w4y7pwJuM861ttA12tImEcYuWikUXCVHD0/5j9v40GnLZ/axuZi4saOFkEcv Nf+eoHhuR0y2A6ShquttwtwUfvYeeR/L88CvR9toM3U4C4wqcqMpLn4i5NUKw9kCw/ VakuoR1pU/KSR2/l0vwXlSSbcHMA1MjQ7iaVDmv3RYPzLwu516azjBo3BayK6bamyR kc3EwNWjkE5wA==
Message-ID: <bc490aca-be1c-0a82-f065-1c49688ddeb3@puck.nether.net>
Date: Wed, 26 Oct 2022 16:20:41 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Content-Language: en-US
To: RFC Errata System <rfc-editor@rfc-editor.org>, sandy@tislabs.com, aretana.ietf@gmail.com, jgs@juniper.net, andrew-ietf@liquid.tech, morrowc@ops-netman.net
Cc: iljitsch@muada.com, sidr@ietf.org
References: <20221026160313.8AD91C8AE9@rfcpa.amsl.com>
From: Wes George <wesgeorge@puck.nether.net>
In-Reply-To: <20221026160313.8AD91C8AE9@rfcpa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/B3nkTCz4QHgeXFIVFsKby0fTEGs>
Subject: Re: [sidr] [Technical Errata Reported] RFC8206 (7183)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2022 20:21:00 -0000

This should be rejected. it is not a correction of something inaccurate, 
but rather a clarifying question.

To answer the question, the statement refers to the fact that an SP can 
enable AS transition mechanisms and complete one part of the transition 
(their side can move from ASN to ASN') without coordination with the 
customer - thus the transition is transparent. But the SP can never 
disable those transition mechanisms and complete the transition fully to 
the new ASN without coordination with the remote side to reconfigure and 
point to the new ASN'

On 10/26/2022 12:03 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC8206,
> "BGPsec Considerations for Autonomous System (AS) Migration".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7183
>
> --------------------------------------
> Type: Technical
> Reported by: Iljitsch van Beijnum <iljitsch@muada.com>
>
> Section: 3
>
> Original Text
> -------------
> Since SPs are using migration methods that are transparent to customers and therefore do not require coordination with customers, they do not have as much control over the length of the transition period as they might with something completely under their administrative control
>
> Corrected Text
> --------------
> Since SPs are using migration methods that are transparent to customers and therefore do not require coordination with customers, they can transition at any time without delay.
>
> Notes
> -----
> I have no corrected text. If the migration methods are transparent, how is it possible that SPs "do not have as much control over the length of the transition period as they might with something completely under their administrative control"? As it's transparent they would in fact have complete administrative control.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8206 (draft-ietf-sidr-as-migration-06)
> --------------------------------------
> Title               : BGPsec Considerations for Autonomous System (AS) Migration
> Publication Date    : September 2017
> Author(s)           : W. George, S. Murphy
> Category            : PROPOSED STANDARD
> Source              : Secure Inter-Domain Routing
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG