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

Robert Raszuk <> Sat, 13 August 2022 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 030F7C14F6EB for <>; Sat, 13 Aug 2022 10:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gv1nI9EVdbMp for <>; Sat, 13 Aug 2022 10:56:24 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id CA56FC14F613 for <>; Sat, 13 Aug 2022 10:56:24 -0700 (PDT)
Received: by with SMTP id gk3so6955569ejb.8 for <>; Sat, 13 Aug 2022 10:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <79FFB948-84F1-4620-8FE5-377B57F908C4@hxcore.ol>
In-Reply-To: <79FFB948-84F1-4620-8FE5-377B57F908C4@hxcore.ol>
From: Robert Raszuk <>
Date: Sat, 13 Aug 2022 19:56:37 +0200
Message-ID: <>
To: Jeff Tantsura <>
Cc: Joel Halpern <>, SPRING WG List <>
Content-Type: multipart/alternative; boundary="000000000000e2549505e6231d94"
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: 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

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.


On Sat, Aug 13, 2022 at 1:04 AM Jeff Tantsura <>

> 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 <>
> *Sent: *Wednesday, August 3, 2022 7:45 AM
> *To: *SPRING WG List <>
> *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.
> Yours,
> Bruno, Jim, and Joel
> _______________________________________________
> spring mailing list