Re: [spring] Proposed policy on reporting implementation and interoperability
Joel Halpern <jmh@joelhalpern.com> Fri, 12 August 2022 22:03 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 54DA7C157B3E for <spring@ietfa.amsl.com>; Fri, 12 Aug 2022 15:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.129
X-Spam-Level:
X-Spam-Status: No, score=-2.129 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 c4scUNLzoteM for <spring@ietfa.amsl.com>; Fri, 12 Aug 2022 15:02:58 -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)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797F3C14F740 for <spring@ietf.org>; Fri, 12 Aug 2022 15:02:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4M4HjZ1Gtxz1pP1p; Fri, 12 Aug 2022 15:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1660341778; bh=UOYN9ied5dMaYfdMAIJPHEnAQBUHCwsJdanz0BuszXI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=XCShvGlS4+x8R3KbfVkl2vMQbNVPg5FfSEiyJeHF8L8nOkaMc0YhXLO0TilDCgCjG JEoAv2+W/mknOMkmHT8jRQNRCivr40hmF5f6oNoyGjwVkHHgdavfdZTecaGnkPJZ1t Mhx4cRqqR5tukElrfkNFRRamYY4tnzJ9gnqOFmbk=
X-Quarantine-ID: <w8VdNokty4we>
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 4M4HjY4RHGz1nsqY; Fri, 12 Aug 2022 15:02:57 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------UJB0WreVOdwjWYkhu0RWHV9y"
Message-ID: <0954471f-a23f-8a2b-8a4b-0ac80a24f49c@joelhalpern.com>
Date: Fri, 12 Aug 2022 18:02:56 -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> <CAOj+MMG=LXcowA7E4nO_EhUA598oQMSY+Z5vwD54tRt95Or5fQ@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAOj+MMG=LXcowA7E4nO_EhUA598oQMSY+Z5vwD54tRt95Or5fQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/DIsQMiyH0wBizr2AjWVNXGctGaM>
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: Fri, 12 Aug 2022 22:03:02 -0000
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 >
- [spring] Proposed policy on reporting implementat… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Dhruv Dhody
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Eric Vyncke (evyncke)
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Tony Przygienda
- Re: [spring] Proposed policy on reporting impleme… Acee Lindem (acee)
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Jeff Tantsura
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Ketan Talaulikar
- Re: [spring] Proposed policy on reporting impleme… Gyan Mishra
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Ketan Talaulikar
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Ketan Talaulikar
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Adrian Farrel
- Re: [spring] Proposed policy on reporting impleme… Robert Raszuk
- Re: [spring] Proposed policy on reporting impleme… Chengli (Cheng Li)
- Re: [spring] Proposed policy on reporting impleme… Boris Hassanov
- Re: [spring] Proposed policy on reporting impleme… Suresh Krishnan
- Re: [spring] Proposed policy on reporting impleme… Joel Halpern