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

Joel Halpern <> Fri, 12 August 2022 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 993D0C14CF16 for <>; Fri, 12 Aug 2022 15:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Status: No, score=-2.827 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_LOW=-0.7, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KRtBYvt2Z40E for <>; Fri, 12 Aug 2022 15:48:59 -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 B913BC157B39 for <>; Fri, 12 Aug 2022 15:48:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4M4Jkg4JqSz1pXvb; Fri, 12 Aug 2022 15:48:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1660344539; bh=dZ6oQX7kKb8VYUho/oQbampRONuG7bPrlOXSPYnRwp0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=iMq5dZEgvQHQNE07QAtC4WSDCzHxnNVzeXS0ZHeYtq1Acs4bnrkiBOczhQbEyVP+o ooDgBFzdnI5yU+usvuEchqJmVEXzAyx/4uSa7DFB8+uM0du5cxfNb+txifOPsrPing 9dVdy6Tb/ZiSpLRew6BpXpsOlKgpXXMifPaPHb8U=
X-Quarantine-ID: <M694YUo6DJU9>
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) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4M4Jkg05Thz1pWGn; Fri, 12 Aug 2022 15:48:58 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------DMh0NSlWyHYPxVh220JoD0mT"
Message-ID: <>
Date: Fri, 12 Aug 2022 18:48:57 -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 <>
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: Fri, 12 Aug 2022 22:49:03 -0000

With regard to item 1, reasonable people may differ.   If the working 
group wants to require that all implementations listed in the 
implementation section MUST implement all MUSTs, then we could do that.  
But unless we hear from more people, that is not our current expectation.

With regard to #2, the point of this exercise is the snapshot. The issue 
with the web page is not getting the page.  It is someone actually 
maintaining it.  If folks want to, sure.  But that would be a separate 



On 8/12/2022 6:10 PM, Robert Raszuk wrote:
> Joel,
> On #1 IMHO implementations of all MUSTs is what is necessary 
> for interoperability. If something is not needed for base 
> protocol functionality it should not be MUST in the first place. After 
> all, aren't we about assuring interoperable implementations here ?
> As to #2 - no need for separate web pages. IETF wiki works fine with a 
> markup syntax. So all that is needed from any WG is just to setup a 
> single wiki page - rest is just simple text :)  Alternative would be 
> to keep such reports on the Wg git.
> The problem with including any implementation details in the spec is 
> that the frequency it gets updated is much higher then spec can handle 
> .. especially after freezing it after publication.
> Thx,
> R.
> On Sat, Aug 13, 2022 at 12:02 AM Joel Halpern <> wrote:
>     With regard to point 1 about MUSTs and implementations, we chose
>     this because we recognize the reality that what people say is an
>     implementation of an RFC may not include all the MUST clauses.  If
>     we were protocol police, that would be a problem.  In this case,
>     we would rather know about partial implementations and the fact
>     that they are partial.
>     As for point 2, the purpose here is to capture the snapshot.  If
>     people want to separately maintain web pages, I am sure we can get
>     the pages set up to complement this effort.
>     Yours,
>     Joel
>     On 8/12/2022 6:00 PM, Robert Raszuk wrote:
>>     Hi Joel,
>>     First thank you & AD for initiating this.
>>     Two questions/comments below:
>>     #1:
>>         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.
>>     How can you allow any implementation to be compliant with an
>>     draft/RFC if normative MUSTs are not implemented. That is
>>     extremely risky if I am reading it correctly.
>>     Of course as others pointed out draft may have a lot of optional
>>     elements which may or may not be implemented at the discretion of
>>     the vendor or use cases. But I would not extend it for MUSTs.
>>     #2:
>>     > Including the reports in the document is preferred.
>>     As an example in IDR we converged on documenting
>>     implementations on IETF IDR wiki page. Wouldn't it be nice to
>>     have some alignment in this method across WGs ? At least within
>>     the Routing Area ?
>>     Many thx,
>>     Robert