[spring] Proposed policy on reporting implementation and interoperability

Joel Halpern <jmh@joelhalpern.com> Wed, 03 August 2022 14:44 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B322C15A73A for <spring@ietfa.amsl.com>; Wed, 3 Aug 2022 07:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 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_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 TwyqjJnAyfQs for <spring@ietfa.amsl.com>; Wed, 3 Aug 2022 07:44:50 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 4C73AC15A739 for <spring@ietf.org>; Wed, 3 Aug 2022 07:44:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4LyZQB0bkyz6GB6D for <spring@ietf.org>; Wed, 3 Aug 2022 07:44:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1659537890; bh=gyEIlo46bhy3ESwmTghbF0JHmyeYr89ZHEwGbROyyG0=; h=Date:From:Subject:To:From; b=LYV8HItk/CHvTA4nLhpuJX2tgGd/tuOjYzF9/a3xy9e+U3nZWwWEUqubzoIN+O3vS 5YstARSEmUmeIaK0HRRcW9ywz4uokNzzDhRzEeFb+icn5ruxsYT1MMMJbIyyX+Fbod kcv7N8n1vygLbKUqKOVDAlHdcbJR0F2w501lHwIw=
X-Quarantine-ID: <LGNgQB76xriw>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.23.181] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4LyZQ94hDFz6G8qq for <spring@ietf.org>; Wed, 3 Aug 2022 07:44:49 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------hlmDX3I2RqIy0eo6f0dsyH2r"
Message-ID: <9c7ac280-c1f7-956c-cdbb-2b0745aaf2fa@joelhalpern.com>
Date: Wed, 03 Aug 2022 10:44:49 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
From: Joel Halpern <jmh@joelhalpern.com>
To: SPRING WG List <spring@ietf.org>
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9LmFULcB9cwCAbYBYxB6_rUF8zo>
Subject: [spring] Proposed policy on reporting implementation and interoperability
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2022 14:44:54 -0000

SPRING WG:

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