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

Robert Raszuk <robert@raszuk.net> Sat, 13 August 2022 17:56 UTC

Return-Path: <robert@raszuk.net>
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 030F7C14F6EB for <spring@ietfa.amsl.com>; Sat, 13 Aug 2022 10:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 gv1nI9EVdbMp for <spring@ietfa.amsl.com>; Sat, 13 Aug 2022 10:56:24 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 ietfa.amsl.com (Postfix) with ESMTPS id CA56FC14F613 for <spring@ietf.org>; Sat, 13 Aug 2022 10:56:24 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id gk3so6955569ejb.8 for <spring@ietf.org>; Sat, 13 Aug 2022 10:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=nrssLeM1f4QLuqFVOvrATAdfvtEqytjG6XtH9YpTsCk=; b=VlmEX/lcIJ+dHYSGqsq5spE8b4Wiv/OEPtLZsZ1mNo1fkuNrB/BkvS/nXkq/C2HSfz N62+59jL9q6ITT6IcGeMYxCk8Dk4QA9+hXGZMy2Y457N3ND/QG8qrZXoJcDPaxU/GeAM sUYI3yXfqHOeADYo/kjTAIlDEzhRPmYP+pnmN2Lq7p1lXnPMIEIaZzUjrwSGhQSdvT01 yTjS/pL9bt80UDy1tbT0xsB2fMQCttXM8fSIT9WB1wcxQsVmKC7HNE1EEjUiheDdK4s1 rsrtqx35qL3/0ePCoT2hCzebfI/OVl+9CrSkl0gCTBpqqlcs9pT4ILaCj88GHWoBaUn3 pYPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=nrssLeM1f4QLuqFVOvrATAdfvtEqytjG6XtH9YpTsCk=; b=XShTotjXLmi/2DjS8tMb/4ADFgg2J1hJ1UOiXJNzVK2zfaYbX6F6R3ucH2rWeIa/Tj nrrTYGXo/ukepMtt18My/k6uYWS++oXg6C2j6Bb9v/WVwosMBLRh5WM+6cwZgwjRc9LR lULFecK3fubtW1H97IyXsZU2TJGG+lEw4QPvmPMnsVZBuvbRIZmzKCIUSJAvCDxkzLsn Zq+7wvgeyfJ5gJz9N437BDN93c7CQdb6Bj077aKVtcXTn7wKyCMrj6ufYBsO60rkuu8m Iak2NWs8fEQ7VrPIu+KlbE3L74qZweYlMuMbufWTQE/dxmpA+GjCqEvgCpUGMLiY1EEL fB+Q==
X-Gm-Message-State: ACgBeo0K8Y6Cps9f43cDyNBFdSSTeCkfC7B/idyRnQ5YMtwoEN4oGh5J eOLsq7bHZLCKri0yZK4d5NKXlfqreUU9Dd06apIFLmOqJtlXJg==
X-Google-Smtp-Source: AA6agR4XjoIXia2pvcrGD9WpHl+UgTl62YYAsHAA00rwgZVw6sRtFMSXE+3I/gmYio4rvv5IWs86EvBXsnkNlbspyPM=
X-Received: by 2002:a17:907:1df1:b0:730:b058:ef95 with SMTP id og49-20020a1709071df100b00730b058ef95mr5995051ejc.600.1660413383162; Sat, 13 Aug 2022 10:56:23 -0700 (PDT)
MIME-Version: 1.0
References: <9c7ac280-c1f7-956c-cdbb-2b0745aaf2fa@joelhalpern.com> <79FFB948-84F1-4620-8FE5-377B57F908C4@hxcore.ol>
In-Reply-To: <79FFB948-84F1-4620-8FE5-377B57F908C4@hxcore.ol>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 13 Aug 2022 19:56:37 +0200
Message-ID: <CAOj+MMHQ_xGe9yF4unWGAY4y+d2ZtLvzwq6QxYdQQzKNCJdfXg@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Joel Halpern <jmh@joelhalpern.com>, SPRING WG List <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2549505e6231d94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/VAZCyvY7C_GibIWBTs1ffyo0Xy8>
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 17:56:29 -0000

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 <jmh@joelhalpern.com>
> *Sent: *Wednesday, August 3, 2022 7:45 AM
> *To: *SPRING WG List <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
>