Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Donatas Abraitis <> Thu, 24 September 2020 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D2BA3A1222 for <>; Thu, 24 Sep 2020 11:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h2CIvh7zsY27 for <>; Thu, 24 Sep 2020 11:40:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23B313A1129 for <>; Thu, 24 Sep 2020 11:40:26 -0700 (PDT)
Received: by with SMTP id b22so4999393lfs.13 for <>; Thu, 24 Sep 2020 11:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ji2EUPyf5O3CI84wtFzIm14qz9WoYIhAkLSfvVP0Joc=; b=Ei6ERHZp+4oJuuzSSBhcTxWSItF3qbYn2AB/v7HjmujEe/1nVGljgt2I1/wjxlCMrC WePti9I7SuESIT4m81wNT+DtSKub7FvOXVNv5IUKO7eKZoON2YWz8XaI8N9cirISj5qB BrGE6iLsECgqGeaJUW2nX7afxA2tLjcQHE1uDS+4ezJlrlAGdiz2aCavBBIkarurN8KE HXHbi2rcZDzoQOCF7nDAwQJGO0z32yYic0nzSyd5NLPM0LRQEM/nqc1+LQ6zYWOzZ9qm D/CaCauOEfBxSMlsob652X6Vf3PsdU9ThYTTZxbucP04h6HsuSiBi+j1cVSJ080vk2QC 6sCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ji2EUPyf5O3CI84wtFzIm14qz9WoYIhAkLSfvVP0Joc=; b=EGkfd8vnPWvDict0kPY7cBIEkJcuz1dpwJaGRsiz+vG95cCT/n6RnbCs5paVe0Bg2n jXjf/WDEIrOGZKPE2O2XBDjix1E8l/mlZSvYpjEo3ETNaTh3D9z/oGDFicZ83dDrsaTI VAMRP+dkPjiY4/l6LdTLIiY9KlOhEq0AiKIf/l7w/FNuLqXAjZQNDlShRBhuNvuhb24j TsbtwLBHEDssd+qvj4vZKK6guRay4A1woQkWyDHXD4YwqV+yeqECLo0kvY8zIjYBcZEI Lpdqk67XnQHMkqtlysSXvlytxVXBOU8g/3Vl+XdeioFOdx+jKcFoz0KPuo3C0iV1p2Se 9CLw==
X-Gm-Message-State: AOAM533Dyn1hOjc7hyllSae3KObVq8NagRglcCQHsqWD1s9NRMl1+OfI 5ZiBBXqYn9vfVhFUai25wB81nh+zhoBdIMiO
X-Google-Smtp-Source: ABdhPJyX9MDb8DiSYOy3yjQTKmla0TdiJXOvd6n/nzvsos+KDt/mXJYq7FhfCeL5UymPbZ+dTYPv6w==
X-Received: by 2002:ac2:518d:: with SMTP id u13mr66750lfi.589.1600972824351; Thu, 24 Sep 2020 11:40:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id e65sm58877lfd.143.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2020 11:40:23 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-FE64ADF9-D97D-4DF0-AA8D-E82645130EAD
Content-Transfer-Encoding: 7bit
From: Donatas Abraitis <>
Mime-Version: 1.0 (1.0)
Date: Thu, 24 Sep 2020 21:40:22 +0300
Message-Id: <>
References: <>
Cc: Robert Raszuk <>, IDR List <>
In-Reply-To: <>
To: John Scudder <>
X-Mailer: iPhone Mail (17H35)
Archived-At: <>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Sep 2020 18:40:29 -0000

Hello, guys,

>> But who will work on it if authors would not be interested to change the draft once it becomes a WG doc ? 
Not sure, what is "change the draft" in this context, but I'm ready to do changes if needed.

Sent from my iPhone

> On 2020-09-24, at 21:25, John Scudder <> wrote:
>  On Sep 23, 2020, at 3:59 PM, Robert Raszuk <> wrote:
>> PS1. And on the other hand if it is not adopted here it will likely get published as an RFC anyway in the ISE track. So honestly I have no idea what's best for BGP. If it would be my call
> It is your call — well, what I mean is that this is exactly the kind of issue that should be discussed during this adoption call. So thanks for bringing it up.
>> in such a situation I would perhaps recommend to adopt it and repackage in a different encoding envelope.
> That’s certainly an option that can be on the table, and if others are interested in the same way forward, they should follow up. It would probably help to discuss what that “different encoding envelope” might be, at least in general terms.
>> But who will work on it if authors would not be interested to change the draft once it becomes a WG doc ? 
> Indeed that’s a key question. For that matter it is for every draft we adopt: not only “do you think it’s a good idea” but “are you willing to put effort into it” (including contributing, reviewing, etc). I think it’s a good idea that everyone should have a pony, but I’m not willing to put effort into it :-). 
> But, in this case it seems like the ’not be interested’ part is getting a little ahead of ourselves. Donatas is in the cc after all, we shouldn’t need to speculate about his preferences. Donatas, as the author, what’s your reaction to Robert’s proposal? (It is OK to say “I would need to know something more specific an just ‘different encoding envelope’.”)
>> PS2. Assume this goes on as ISE RFC. And perhaps magic happens and IDR defines a different encoding for exactly the same information down the road. Would IDR or GROW have power to move ISE RFC to historic or obsolete status at that point ? 
> My guess is that the answer is “no”. Historic is — as far as I know — a designation specific to the IETF standards process. The ISE is — as far as I understand it — not part of the IETF standards process. Figure 1 of RFC 6635, "RFC Editor Model”, seems to confirm this. I’ll see if I can get an authoritative answer.
> —John