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

Joel Halpern <jmh@joelhalpern.com> Sat, 13 August 2022 18:02 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 1B156C14F744 for <spring@ietfa.amsl.com>; Sat, 13 Aug 2022 11:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.127
X-Spam-Level:
X-Spam-Status: No, score=-7.127 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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: 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 uFFHeCeUFbAt for <spring@ietfa.amsl.com>; Sat, 13 Aug 2022 11:02:33 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 0A9A9C14F724 for <spring@ietf.org>; Sat, 13 Aug 2022 11:02:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4M4pKh57kgz1nshF; Sat, 13 Aug 2022 11:02:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1660413752; bh=4HEmBlHnLMR09be/j04joqWesgDdCIrk3U8mtKWUZ4g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Ol11AX4Zj01rTk9HG0XuI8aAK2DqfiQMh1zw+QdtmqvDwWUUFdscm0GqmePhTfNjd 2s/89Kvt/q6fEVbBtcL/yvsjhuzloC0CQWad0mTODAtMsU2jF+uggiwUNFKXQpy2Xu T2apK5vKEuH4akTgSdzioq4dweTKL2lTToMprKtM=
X-Quarantine-ID: <G6zoqK68-OSX>
X-Virus-Scanned: Debian amavisd-new at b2.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) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4M4pKg5j1Wz1pNyD; Sat, 13 Aug 2022 11:02:31 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------C20JkNFSaTWL6n5hV7qgwEHb"
Message-ID: <3f169b37-74db-f1a2-e6c1-bfeb34a6dd63@joelhalpern.com>
Date: Sat, 13 Aug 2022 14:02:30 -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: Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG List <spring@ietf.org>
References: <9c7ac280-c1f7-956c-cdbb-2b0745aaf2fa@joelhalpern.com> <79FFB948-84F1-4620-8FE5-377B57F908C4@hxcore.ol> <CAOj+MMHQ_xGe9yF4unWGAY4y+d2ZtLvzwq6QxYdQQzKNCJdfXg@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAOj+MMHQ_xGe9yF4unWGAY4y+d2ZtLvzwq6QxYdQQzKNCJdfXg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/5Z99S32qgP2ap0bE_eKWCqDLCDU>
Subject: Re: [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: Sat, 13 Aug 2022 18:02:37 -0000

Robert, why would we discard information?  It seems that if folks do 
report such partial compliance, it is helpful to include it. Whether 
anyone will make such a report remains to be seen.

Yours,

Joel

On 8/13/2022 1:56 PM, Robert Raszuk wrote:
> Hi Jeff,
>
> > 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.
>
> Glad we agree on that.
>
> But my point was not so much to claim 100% compliance or 90% 
> compliance. My point was that any report which indicates even a single 
> MUST of a given spec being unsupported should be discarded right away.
>
> Imagine that the implementer chooses to ignore MUST and not to drop 
> the packet when decremented TTL is 0 and thinks let the next hop 
> drop it to save his hardware.
>
> Frankly I am not sure what Joel (and SPRING chairs) had in mind even 
> remotely allowing partial support for normative MUST for any draft.
>
> Best,
> Robert
>
>
> On Sat, Aug 13, 2022 at 1:04 AM Jeff Tantsura 
> <jefftant.ietf@gmail.com> wrote:
>
>     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.
>
>     Cheers,
>
>     Jeff
>
>     *From: *Joel Halpern <mailto:jmh@joelhalpern.com>
>     *Sent: *Wednesday, August 3, 2022 7:45 AM
>     *To: *SPRING WG List <mailto:spring@ietf.org>
>     *Subject: *[spring] Proposed policy on reporting implementation
>     and interoperability
>
>     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
>     spring@ietf.org
>     https://www.ietf.org/mailman/listinfo/spring
>