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

Joel Halpern <> Wed, 10 August 2022 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 192C2C136338 for <>; Wed, 10 Aug 2022 05:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, NICE_REPLY_A=-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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JirMTB6lCGVZ for <>; Wed, 10 Aug 2022 05:44:53 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 796B3C136333 for <>; Wed, 10 Aug 2022 05:44:53 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4M2qQY1Pr5z6GnBF; Wed, 10 Aug 2022 05:44:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1660135493; bh=F1kl0KhauWdJ0bf4bWlzfBgdpVr/pC2yrEdmlx6+qwk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Sz73dxzvjV2h9Tlj89sTDTW6w3iSdNFEw+WiAEfjBbL5nRYwWCfS7DtDSjMD+wr+M UglZRI7L0vCE7pH60dav7usKIz/4XkvPGoC8PO10oCEALLIEyE4TxBkTwysxuYj5Sh sy1eBP5yxGeTK+LvreXvy9bcBkatnYjqtV2gd6zo=
X-Quarantine-ID: <9J1KJBkmJjaa>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (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 (Postfix) with ESMTPSA id 4M2qQX0tqLz6G7hL; Wed, 10 Aug 2022 05:44:52 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------qvWGVtCIsLBUQOysYMzD5UB3"
Message-ID: <>
Date: Wed, 10 Aug 2022 08: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.12.0
Content-Language: en-US
To: Dhruv Dhody <>
Cc: SPRING WG List <>
References: <> <>
From: Joel Halpern <>
In-Reply-To: <>
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: Wed, 10 Aug 2022 12:44:57 -0000

Thank you Dhruv for reading and commenting on the policy.  While I think 
the implementation and interoperability section will apply to even most 
informational documents, I am happy to allow the option of "does not 
apply" to cover those cases when it truly doesn't.



On 8/10/2022 6:17 AM, Dhruv Dhody wrote:
> Hi Joel,
> One suggestion, apart from "none to report" it might be a good idea to 
> also have a "not applicable" option for the WG's informational and 
> architectural documents to clearly distinguish between the the case of 
> no implementation exist v/s applicable.
> Thanks!
> Dhruv
> On Wed, Aug 3, 2022 at 8:14 PM Joel Halpern <> wrote:
>     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
>     _______________________________________________
>     spring mailing list