Re: [spring] Proposed policy on reporting implementation and interoperability

Tony Przygienda <> Fri, 12 August 2022 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72806C15C501 for <>; Fri, 12 Aug 2022 08:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Status: No, score=-7.108 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rMK0-Pzl2spB for <>; Fri, 12 Aug 2022 08:02:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (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 (Postfix) with ESMTPS id 02D83C15A73A for <>; Fri, 12 Aug 2022 08:02:45 -0700 (PDT)
Received: by with SMTP id 68so1017768iou.2 for <>; Fri, 12 Aug 2022 08:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=Dsm96t46p8HRMmVil5LS3MGqIh9xhPOZaCrcr4hw5Z0=; b=BDkL7oYxZKfTd1kV/DSPgtkh7cbAejx2O4Zm7cNmGc/BZx4+1/HSSYxTH+aQQtyehG 6qUxTHQ57mgXJi09L2t4BxJ1DDBkPb9bEWmm5Ij4QE+Z1gdV3vggT7+ffZRStAOBkV3p RHcUDwvUugixAF4WDFEhsMby9dU4RrKyrM1sMS9IJ3JDB+4HGI7YFzRM0kHW0Bf0ULR3 UK05LCl+Ui8nz7ZbhkCSA6k89NFC4kjqvwIWPEvuv2HANibKDQ7KdPEDpT9e/7gnzYyB yJ5VUVSRxzBhTc+Gx/ha2tymKclNMBozpe8BUzPNyDqn8vHnR/8vVbsPlwEcTdhhuLMC 0qqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Dsm96t46p8HRMmVil5LS3MGqIh9xhPOZaCrcr4hw5Z0=; b=HskPov3IXkFp+jelYTz8nW1oJ8nVsJXPtuOgG0WqFMykwxjxTcQLDB9NXX5SjFuWSj 5l9CRu2QGN6t1iL7TsQJXf49mP/l5yi0hy2XUNFx3Q9B2ZW3HOPB4ltheKl+Z070jrTr qsOJC0GI8JMXBTCr3WXVQ5bjVxu3h4YocscgzRrEitYGtC4HTGBDjjrhnSP80UNRsDNE BD+aKwSEMi3BpxOeRHj99pi6LjVZTLLOM+j0pgPp2vTJ4NsRgCcY5w3EZNNAF1EmPOx1 0RsD+mNy7QfIdJ+XtznPsU23rHOZoft1ZFlCp0f0XSQ6HyVFzgOdB1jsX+Ct/4Dg+D7N GQMg==
X-Gm-Message-State: ACgBeo0iMNPo1wKxgfWuOpoFOYaS/bXBVKQR1AXObxu4ZMwwE3UUgxSE 3hmfrABF3vVDeRorLD3TK/Azw2ypwDlW8ULvFO4=
X-Google-Smtp-Source: AA6agR49ayuhu3LttuJCUHdWqBLwBdvacma66S3tSu7NpcU59Rk9xRENwZLucUc5BWYQDavXiX3V2/UZ9WOmCHiCzoE=
X-Received: by 2002:a05:6638:31c2:b0:335:dd22:83ec with SMTP id n2-20020a05663831c200b00335dd2283ecmr2116614jav.88.1660316563631; Fri, 12 Aug 2022 08:02:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tony Przygienda <>
Date: Fri, 12 Aug 2022 17:02:07 +0200
Message-ID: <>
To: "Eric Vyncke (evyncke)" <>
Cc: Joel Halpern <>, "" <>, Andrew Alston <>, John Scudder <>, Alvaro Retana <>
Content-Type: multipart/alternative; boundary="000000000000fd712405e60c92b2"
Archived-At: <>
Subject: Re: [spring] Proposed policy on reporting implementation and interoperability
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Aug 2022 15:02:50 -0000

On Thu, Aug 11, 2022 at 3:58 PM Eric Vyncke (evyncke) <evyncke=> wrote:

> Bruno, Jim, Joel,
> Without any hat, or only with the experience of reviewing so many I-Ds
> from different areas and having implemented a couple of proof-of-concept
> implementations of various IETF drafts.
> The following are just comments for discussion, not criticisms because
> indeed running code is important at the IETF.
> RFC 7942, an IETF stream BCP (i.e., with IETF consensus), is already
> useful but **optional** while the proposal below would be mandatory.
> Hence, I share Dhruv’s question: will it also apply to experimental or
> informational documents or BCP? Joel, thank you for your reply to Dhruv, it
> seems a sensible solution.
> You may be aware of a long-standing project/idea/wish of the IESG to have
> a **living document concept** that could be updated for years after RFC
> publication. As you can imagine there are too many gears to make fast
> progress on this topic, but the current proposal is to move the ‘living’
> part of the doc to a github repo under the IETF organization (e.g., done in
> MOPS). Wouldn’t it be a better fit than a section ‘carved in stone’ forever
> (even if time-stamped) in an RFC?
> Getting an implementation could sometimes be easy in Python or Go in Linux
> at a hackathon  ;-), or in “slow path”, a little more complex in P4, even
> more in silicon... the ultimate step is of course a **deployment**
> outside of a virtualized lab:, i.e., in a production network. Of course,
> deployment (and interoperation) in a production network is the Graal ;-)
> But, where to put a useful but realistic needle **without delaying** the
> standardization process ?

Getting things deployed is a monumentous task mostly, often deployment
happens based on RFI/RFPs using RFCs (seldom based on drafts IME since
those are moving targets). And normally, it's not RFCs being published as
deployment documentation (though it happens, e.g. VxLAN).  So, good
potential for an unresolvable dependency circle if deployment documentation
has any influence on RFC status.

-- tony