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

Robert Raszuk <> Fri, 12 August 2022 22:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB905C157B4D for <>; Fri, 12 Aug 2022 15:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.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_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 U2m9Tm2IxECa for <>; Fri, 12 Aug 2022 15:10:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (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 AEF10C157B43 for <>; Fri, 12 Aug 2022 15:10:10 -0700 (PDT)
Received: by with SMTP id e13so2860667edj.12 for <>; Fri, 12 Aug 2022 15:10:10 -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=5tYff1mM/DrLunRyzNC5hnRat/Cv6CjHl4d84QoxOTA=; b=GScQGt/FWp11+0MwABSSzzKBKSn2Xp5mFk3gqqqPelDdX0iS2FxuKIqAiVoVl8zr5E VS0Qc+2V4Lw20oMt1GIge53AHObxoo93hqt+3epHJcCyXcoaS9ENHotpSVM/BIkXLU4P cmBGZlAHxAeCdE3ul9wYzmH8meeTtmgcQSLnglB+WfWRkp+HKiZRtzEVOvZBpF49JYoR DCE3QMFAHJBXDZ+26aqNkQ21TkmgdJIHhaBxaghS8vxOm2J4VOs3OFMJIPSY+z1mOnd5 R6ciAT2IvDvBX6iV8bBu2BDkV57zJ0HUG+xygzaT5awpQ8yX2+mvHdHI3qz6sLe6I8A+ nDUQ==
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=5tYff1mM/DrLunRyzNC5hnRat/Cv6CjHl4d84QoxOTA=; b=H6aiq5BVgScjVNvUR88DVc/X/fRihjJ+MnqM1EiTUsyCx8Ka8QjaGfozflpZib27SH CKLGf87CsscmG7TryDHVH2AVl8XCiKaELo+pwXsp9qvfQsItUsFb2EfyzHaaiDADw05B rriARF+ItN0ppEsupVLnJwLXHs31XVZC5Zx2EeuyqygLAT3PgU24lvsGQgCzhoUEvFn8 w7Dmoc6MCkCYpyDWBSN5MwvtB179olVz0ImtC21axlMhaEXhAhIHSd3/aYcjBbKhXGu2 1Zq6qNW2gzBj/AQCM3FYCe4Qs4aEwZyU7MDGHyLQoCFq1H6CPJQQ8VkAjURPghQKm1MW d/9g==
X-Gm-Message-State: ACgBeo0xPx2dAkCqVzsjn942JBlpu88kq35bYtSDqRgTXk7N7gJf+xZv N6CvqlXmEpBId3hLemLUsmm+PYRBqE9W/x//Yt3u72LmFp8=
X-Google-Smtp-Source: AA6agR6HeVD4f8dVKU50zvW8vP8Z1h+YRUWMN/4VAISQLqYjTQpVSgbz2CEOgMfGaydvmycduWFIRjw1UZDw2a/YR5M=
X-Received: by 2002:aa7:d513:0:b0:43d:5c81:4f71 with SMTP id y19-20020aa7d513000000b0043d5c814f71mr5204193edq.308.1660342209180; Fri, 12 Aug 2022 15:10:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sat, 13 Aug 2022 00:10:23 +0200
Message-ID: <>
To: Joel Halpern <>
Cc: SPRING WG List <>
Content-Type: multipart/alternative; boundary="000000000000958f1905e6128bfb"
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:10:14 -0000


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.


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