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

Jeff Tantsura <> Fri, 12 August 2022 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E156C157B3B for <>; Fri, 12 Aug 2022 16:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Status: No, score=-2.007 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, MIME_HTML_ONLY=0.1, 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] 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 EFYhGL6NPQGJ for <>; Fri, 12 Aug 2022 16:03:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1033]) (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 D30E9C157B39 for <>; Fri, 12 Aug 2022 16:03:58 -0700 (PDT)
Received: by with SMTP id o5-20020a17090a3d4500b001ef76490983so2131592pjf.2 for <>; Fri, 12 Aug 2022 16:03:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=content-transfer-encoding:to:references:message-id:in-reply-to :thread-topic:subject:from:date:mime-version:from:to:cc; bh=NeZDYiQTVLBEzbXpdXvFJEVJZsToWsAewHSyiUDusLc=; b=ZIaDZbdpYwMUOuTTN4ZCGDLeNM87+ODlGT7Wl9bGwblZp7nVkE7hZGbofiAhzSR0JG jJzce5FKi3QgzW2WHMbj+0WHozL6u9Et/UDGJ7rk9qbQlr8xzIWJgzuSMrf6IZo6a2aE QT8t4WXOJaZIeoZrpAuE4ePbsjM8VHT6M3Ao2hTxJiiJDF2fvdDwK8QdS9gDNyETn/BT 96iu0+T5WQlXoufE+xkoBy6Ypj057OSVIDbMQ/XWYjP5gfQ6uKJmx3kSHS6wE1E8AXJA ncXqjrLiY7OQS24C/XpTMa03bAEUWYuyGXjtpycnM0QFhYUrCu5I9y4Hbqb2SPSxhIwD VSbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=content-transfer-encoding:to:references:message-id:in-reply-to :thread-topic:subject:from:date:mime-version:x-gm-message-state:from :to:cc; bh=NeZDYiQTVLBEzbXpdXvFJEVJZsToWsAewHSyiUDusLc=; b=vvR6JOv8Q1lqQ57Q/jl9BwWdsmnR5LotOusGZtcn+5zqt0jqDeW25VwexZZ8uIqS5L ObniAek0BVZedld61mrvpMOH6EWlHtDP2qbNSGguCvI1bXNx42lAOK/F34OG7XjbyY8c K7J7yD4RTAXWtKWbbHuaz629FVVcaJxCMy2VgoDBZW8FdHEXOQrT0VupQiqv141IhY7g OuED3rEhryM34NPH9rGcY6Dtemq4Xs0lxDOdRr1NMibIZJMR1MPLSkpmPZTsbKM+p2W+ O90PGvd7zk+9lHZ7QeySxGBtfcJ6+T1l4Hxfh7tMJBISqrMje+dYcHIwSGoMU7v50Gov mUHQ==
X-Gm-Message-State: ACgBeo0RQIc9RsASWmktPibl3GbRywRFqTCND9v+Ab/S4xFNQhehwNwN ty5aN2/vAAZ6rUa7/wg/RzFdLlbydIQ=
X-Google-Smtp-Source: AA6agR59Bi8g7+TJSnNOvpEDF2E9ShVXjaCDirWARMtkNejp3J7qbpYySOs2saelOrR5xWDm4BStfQ==
X-Received: by 2002:a17:902:76cb:b0:170:9f15:b9a1 with SMTP id j11-20020a17090276cb00b001709f15b9a1mr6189931plt.95.1660345438318; Fri, 12 Aug 2022 16:03:58 -0700 (PDT)
Received: from Jeff-Corp-Win ( []) by with ESMTPSA id a1-20020a634d01000000b0041c66a66d41sm1849167pgb.45.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2022 16:03:57 -0700 (PDT)
MIME-Version: 1.0
Date: Fri, 12 Aug 2022 16:03:53 -0700
From: Jeff Tantsura <>
Thread-Topic: RE: [spring] Proposed policy on reporting implementation and interoperability
In-Reply-To: <>
Message-ID: <79FFB948-84F1-4620-8FE5-377B57F908C4@hxcore.ol>
References: <>
To: Joel Halpern <>, SPRING WG List <>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
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 23:03:59 -0000

Very much in support of the proposal.

I’d expect to see all and each MUST statements implemented for an implementation to be able to claim to be 100% compliant with the specification.

MAY/SHOULD could be implemented or not, however should be addressed in the implementation report, additional (and optional) features that aren’t covered by the specification but could potentially improve it may be discussed in the report for community benefits.  





From: Joel Halpern
Sent: Wednesday, August 3, 2022 7:45 AM
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.


Bruno, Jim, and Joel