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

Robert Raszuk <> Sat, 20 August 2022 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32A3AC14CF09 for <>; Sat, 20 Aug 2022 08:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FaGGUwnC7sY1 for <>; Sat, 20 Aug 2022 08:53:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62b]) (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 70CF6C14CE31 for <>; Sat, 20 Aug 2022 08:53:58 -0700 (PDT)
Received: by with SMTP id gi31so7345667ejc.5 for <>; Sat, 20 Aug 2022 08:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=BWW8ruSfVJwAkp3abIGOGHe/6dhQEEnd5TexgOJ5f1E=; b=dmPr+9n3FwuBTsUgXFO4puB5Bcyj/UsF1V1Z+QOeRvtkxTypcZ4Nf7tMOfbPi9V0A3 GEsVHhMtekfOzxbp+gp636Ricx2UNbL83AsmWl623DUMtt1/7gsHZxnB/RCQZ8M6YCLd F2y2M+KObRi5zGYDDf38/9Ca1YmeWUoOaWzdfyMMWsU88vGIhF8TAIBbSaWsbtnNI+i2 MmmA5z/ZTIVtEde31qXCzljM1TaoHx1ZpVWxB+STUf2/2k3H/tGEf1BfOIV4bIi6yt4F +rTZZLJPEcKSTCHN7gpMcCPxfwTBcjoKKdY70can5igIoXLhD2NfRpAl7DzhAoRXmf71 ivgA==
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=BWW8ruSfVJwAkp3abIGOGHe/6dhQEEnd5TexgOJ5f1E=; b=Ed++5mZ+erHL+cTInMAuoA3i9bntVAkeupMzb5OcpbVGkQzV7NDQeM+Z8ekpKyOcdb rdLiqXBEhmUedUXI0xRldF0sLuTys74//Eosm1KCnzIK78Qjvd7kx4hI7LhE2CcvdiYU 5Z+6XruyGPDOd6GSAElGw57FnprCMKqFkDGul+Is7hRARUhFSQSYmil19GqNokh+LXjy 74AoU8vitH5Epj2Q85eqrySBd0xLlbmVY91Y8UpMNZFgUg/Blf068GV78DqW/hemE3JP QKvzmo8pZxyIzXrNb18ZUvEcexiocFbuCi8xim72PagIWcQnqJSHvChR4yNrTaNW6ka8 LxhQ==
X-Gm-Message-State: ACgBeo1tasz+WrPim1zNhFCV83TyGdVXtJBovmhkV8LBWbiPL0qMo1jO 94mhulXHXSpteGG1yEA9DYvoRGtH3iVjG6HK7cJ8YrSGU4I=
X-Google-Smtp-Source: AA6agR6Gtf9oKYTNSpdpm9idirzPvD/8gFaw/zkzZRP6rT6Yj11+DE0DKaZKZMFLlbkr6xaajL2p0/M4+9oXWjaNJbE=
X-Received: by 2002:a17:907:1dcb:b0:73d:34f7:d39c with SMTP id og11-20020a1709071dcb00b0073d34f7d39cmr4771260ejc.600.1661010835941; Sat, 20 Aug 2022 08:53:55 -0700 (PDT)
MIME-Version: 1.0
References: <> <019f01d8b48c$11bade30$35309a90$>
In-Reply-To: <019f01d8b48c$11bade30$35309a90$>
From: Robert Raszuk <>
Date: Sat, 20 Aug 2022 17:53:45 +0200
Message-ID: <>
To: Adrian Farrel <>
Cc: Joel Halpern <>, SPRING WG List <>
Content-Type: multipart/alternative; boundary="000000000000d83fce05e6ae3846"
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: Sat, 20 Aug 2022 15:54:02 -0000

Hi Adrian,

I 100% agree with you.

However what I understood as "Implementation Section" requirement was as
simple a one paragraph including URL to an IETF wiki page.

Not actual list of vendors and features supported. That would be highly
inaccurate the moment it is posted.

Many thx,

On Sat, Aug 20, 2022 at 1:58 PM Adrian Farrel <> wrote:

> Hi Joel,
> Thanks for bringing this to the WG for discussion.
> As one of the authors of RFC 7942 I want to comment on the idea of
> including this “snapshot” status at the time of publication within the
> published RFC. I think this changes the purpose of collecting the
> information and making it public. It moves from being information that is
> valuable for assessing the status of the work, to something that verges on
> a marketing statement. In particular, companies that are able to get into
> the RFC reporting their implementations will, forever, be named in the RFC
> as known implementations, while other companies (perhaps those who waited
> for consensus before implementing) will be excluded. This seems wrong, and
> while the text you propose to include might make it clear that it is just a
> snapshot at the time of publication, it will still be there as a public
> record. The IETF is not a proxy marketing machine, and this information is
> not useful for the technical content of the RFC.
> When we wrote 7942, we thought about this quite a lot. That led us to
> include:
>    Authors are requested to add a note to the RFC Editor at the top of
>    this section, advising the Editor to remove the entire section before
>    publication, as well as the reference to RFC 7942.
> But, at the same time, we described other places this information could be
> stored and updated, if that is what the working group wants to do.
> Personally, I don’t think it is the IETF’s job to record implementation
> status after publication of an RFC, as this becomes very loaded and
> commercially sensitive. It could be hard to police, and could become
> contentious.
> So, in summary:
> - I support the idea of capturing the implementations status of the SPRING
> work during its development and at the time of publication request.
> - I am strongly opposed to retaining that information in published RFCs.
> - I support am neutral on idea of continuing to record implementation
> status after publication if there is WG consensus.
> Thanks,
> Adrian
> *From:* spring <> *On Behalf Of *Joel Halpern
> *Sent:* 03 August 2022 15:45
> *To:* SPRING WG List <>
> *Subject:* [spring] Proposed policy on reporting implementation and
> interoperability
> At the suggestion of our AD, the WG Chairs have been discussing whether it
> would be helpful to be more explicit, in I-Ds and RFCs we produce, about
> the announced implementations and known interoperability tests that have
> occurred.  If the WG agrees, we would like to institute and post on the WG
> wiki the following policy.  The period for discussion and comment runs
> until 9-Sept-2022, to allow for folks who are on summer break:
> All I-Ds that reach WG last call shall have an implementation section
> based on, but somewhat more than, that described in RFC 7942 (BCP 205,*
> Improving Awareness of Running Code: The Implementation Status Section*).
> Authors are asked to collect information about implementations and include
> what they can find out when that information is available for public
> disclosure.  Documents will not be blocked from publication if the authors
> fill in the section as "none report" when they have made an effort to get
> information and not been able to.
> There are a couple of important additions to what is called for in RFC
> 7942.  We have confirmed with leadership that these changes are acceptable
> in terms of IETF process:
> 1) We will retain the implementation status section when the draft is
> published as an RFC.  In order to do so, the section will begin with "this
> is the implementation status as reported to the document editors as of
> <date>"
> 2) Each implementation description MUST include either a statement that
> all MUST clauses in the draft / RFC are implemented, or a statement as to
> which ones are not implemented.
> 3) each implementation description may include reports of what optional
> elements of the draft / RFC are implemented.
> Reports of interoperabiity testing are strongly encouraged.  Including the
> reports in the document is preferred.  This may include a reference to
> longer and more detailed testing reports available elsewhere.  If there are
> no reports of interoperability tests, then the section MUST state that no
> such reports were received.
> Yours,
> Bruno, Jim, and Joel
> _______________________________________________
> spring mailing list