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

Boris Hassanov <bhassanov@yahoo.com> Thu, 25 August 2022 12:02 UTC

Return-Path: <bhassanov@yahoo.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 80B7FC15256C for <spring@ietfa.amsl.com>; Thu, 25 Aug 2022 05:02:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, FREEMAIL_FROM=0.001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 0lzSuz9V7sLe for <spring@ietfa.amsl.com>; Thu, 25 Aug 2022 05:02:49 -0700 (PDT)
Received: from sonic319-28.consmr.mail.bf2.yahoo.com (sonic319-28.consmr.mail.bf2.yahoo.com [74.6.131.83]) (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 2E6BFC1522D2 for <spring@ietf.org>; Thu, 25 Aug 2022 05:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1661428968; bh=VFKh5QrFziypZSaumZWxY/gVXFwZ13S9v37LEe8Wj1Y=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=ESNzUkY8noTKvCuv/ZnAxc4JhJwh4nbNnOoZklhXct94wbxTY+NDDqwsO6UvNZxapUCRFZHhU7rn5FyYFMIF7lt6HNWztEEN1Dzb6AfGyeixvAut+XhMXBV6sCIpE2KOeGeFsuQtPTSEU32iN5uAwAA9qJZR3Wk0EP1VJ9R5rP2i89bo+t++S9rxvTIx12VPhLUOhgtpWUtqsWP+VkynUD8pVKWDeicqio5LI+SaS0AS52tSKnjXkodtYjRwdC9Gut5cgo99ufMZ+SJecA9PWRgt0FbjiChESC1RYQSAh3oQK1bUHvJuccqQzOTH7ZRs8SrOpPFNFOiUHq+/3JmmJg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1661428968; bh=+vzABWN9vn/YqzlI2lJFBdNFj15BIiYl57V2Duyw7Xn=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=DhZ6qkab3VTaQrIGn2JAbGY+W309QTM4DXOwxqwfcnxjC2Op7UM/iJJWmSoaAX260m0vzIH2y87oGD3qfCWlpq63TG2dJ+yyOhPAuAwrC7a1TmptCBdVOVd1lviirx7urzy1vFhRZeGpgeVrS2cxv34xFOA/QKcK4N740e+RLwnqr1AtI1RWZjLGXiq2/TFd1XIyliQr0URLETBJ/9TS93bpe+mimeKASUdRybMb8vokEJDm78dU9XDcVkmtenqb8T4Pe+0nqE3E+Dso7ynpB/Cc2bbUv0QXGaBeO9RDj10hA2CMEFS8ic3GgtKwU1uJ1jSUHuDFb/5Ud+EQNX7gqA==
X-YMail-OSG: RSfK834VM1mbXqCUNn8RNcPv61cUMeitBjWbUCMscKPtOaC.aCoOtHTT_pSd9WK MOlc55Lz9ZXba6ba1b6tVsOKGhgDy61XH904kDmh16yEswTcvqCVxZPhHxNesI8Zb0r5S0wqV3As pthkCegk_9jIT2Ru_lj2HLE_SR9ki2A7VgOAzkPsfoFdgTR8Gq4S827nbV5cfsno9yGSUzegiEty IWEwxv02PbQ9ewZ65HdacBKj82Eku1SweCV2R.QA7OHm4REH8.XIoquDQe32gJZ7ZFhheSRryrkM OdKXhfcxJRgNpMZx18T5bzhji4BojrPIwxpFg0.J2GpUfTeZv_6yOOJSKDOjsiybY60R.ww_IbUN Tgzudb.7vj1PrsPw04dJonI1rkn.x1DuKcrxPlQ0wMJw.Vg8Sg.znT3RV3pG61pqsbrdDlM_YVlW Y_NSMt3ImtkYh_bNxSomsXr4cr9EReWPwURG9OrOenynkXy7IyTT8XH32MNibyx_.rxZS283BcQQ vl.RILL91yu8x8OeBwu0P3wvAWL0qgWnN1zWI0Lr.jyD9O4BZbVTSONeOcH4FbGDbVf9NvIKsC0G qQOz0hjp31sRFLo1sy3oFVPAys.gRQhh25K4_OdVGbIMPXj9CN5fJFqznh74HFVz0ocbHFMsyQqA 6BJHJypLNFHEKakUpr7nQpu5coa5zCRe2pOux4Zqo_0pJuw0AQLqJ6VEEByguc6i.DLTcEv5I_EZ k9k5TBPxqplvbLWZ2u_d1kSmhilyUEUIjVq_a1AgYcCXIjJSzCIFmr.hS7Y0QfDApqK8Etw0ZKOq AwJWNM3kW8YFXkOBcg2hGehHj2Z9sGGp2qYQO2Bz1WXuSaAxMluYqxK4QSl5Q2LoCjIi2ILhAI0A WKdn1G_nnBKpAFmxCXUcV8C5JEaY9VlqmI_ghlwJvo2ursTaTmW9Q06v7_TI1iwGddtDXPdHJqFA KnNtP1xHG5YBMQOG_tnoTbamnspgcK2.WlwWgsBoWNP5KZAAAGgrI9_UJbs4BHKObxBAvbSGpvRf muP3Z_MzkEwasbrnp8uvD5w47URCIuz3dPRRwPj6K9rXRltHHkbsyUy_K3pY.90Qxy8gZZnJrt6B T2LeTInHCvhBYzVLMejpm2ukdsTHVgePhQ.YL2rbSCXGjTkKrReobEfkreY2hfG2FgVlhR4d8uZN s7p0xzY6Q5qWqZM8vus1U1_ZA1NjcftFv0AW_UzD52cz0tggq78r39Bok5GnGdtzuPgY4LI.nrEw Y04oUmYMnB2DwFIuEvoW6dQPNZWo_asaZjS95oclFQSQF1UpmQhKy6HgpamQR2A4J6Q.EbGEuGQU vNMfG6zNwUoDwpcxwWD_n6H0zGCl4uWREK0olWdBjRHuI_w8i0Ef_4DAMcfKfU5FyWgvJlp6PDf_ A11VtZkDCxMMEfIRyCQWu7aEON1BLXTp8sXmqLnMpjf14rmg.ZH2pCn.bkboiHkjbmJJJDpnZsGc Rkl04EJ1zoy6bOKK3wfgyCEI.AXi1911CYDa8orQw3gZIY8hK2NN3L9eE1eXZ_1y8Cy62yECzZ0x w40rX42KPkZcz_OjeU9cxqNy3N5d_yWgTsgz3nFmMBwWO7dDJB_5C9zCYjFMDrXqfXH4_OOwHEnH Q5lh_gvMWocK_2bvry.U8jnc.itd.lvMBWlSoE_1RANFeJqCgZq9iIMOscgAc4zIScmurXjEVGc0 cpqueR6os0UX8MzM81P0ueTIuZbFuupqLvMC6Ic3ZnAIoyzP.H72KtcD0zwurl7FQagMo7Y9fqzg M5XkHFNRsEK4gwut202lyckUtSiKYA03ybsyNJJ1_8Z1t84MtHQ5e7E6wT3vVmBLHeIFJQRFKTYh g7PoE8opvaip5NUkhBsZntFE_KPd5lXf747ZhJYVJX4YIEpF98DWse_lmqZNxlZVh0v4hDiN2QAX nbIC5wmuXbQeoW1WP7jXL0P7nDs8yhqdG9FE0hp5eysXkBUhLwEbtGjrI4Zz7WEYTntIGvqipMKJ zLC09E5e1pbximQ5AX8n5RHiIPl_F0gJBIpdl7B6m8zRvF.IO0GAGbqJgJcku0S5sxHiiCGhXVbB vvWDkAV85htYbRd1O5hJ0N5s7x_3fqV5ZCmhF.6IEOJAvR8QDQ1FSC0Zvq6jBEBZ0yiE.EtfzXXs wuQxIOehLL0EB4B4xyv_gaT1u5m6NYpJ..WaOjXodel.MViILxiM7iP9u7_qJ6d1ssBO5uODhRYZ W6uS_9f9g
X-Sonic-MF: <bhassanov@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic319.consmr.mail.bf2.yahoo.com with HTTP; Thu, 25 Aug 2022 12:02:48 +0000
Date: Thu, 25 Aug 2022 12:01:48 +0000
From: Boris Hassanov <bhassanov@yahoo.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: SPRING WG List <spring@ietf.org>, Robert Raszuk <robert@raszuk.net>, Adrian Farrel <adrian@olddog.co.uk>, "Chengli (Cheng Li)" <c.l=40huawei.com@dmarc.ietf.org>, Ketan Talaulikar <ketant.ietf@gmail.com>
Message-ID: <2111921098.1560297.1661428908804@mail.yahoo.com>
In-Reply-To: <7d8b1fae875743329675fc07d7866dd7@huawei.com>
References: <9c7ac280-c1f7-956c-cdbb-2b0745aaf2fa@joelhalpern.com> <019f01d8b48c$11bade30$35309a90$@olddog.co.uk> <CAOj+MMG7X2iTY3VGjZogCeNG6_GN8yuzLbUmiJzNSKC5pQXvag@mail.gmail.com> <7d8b1fae875743329675fc07d7866dd7@huawei.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1560296_1816988349.1661428908801"
X-Mailer: WebService/1.1.20560 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/2IJMotRPxWwBpXTB0mm6RUqhBGQ>
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: Thu, 25 Aug 2022 12:02:53 -0000

 
Hi Joel and all,
This is great initiative indeed. and I support it
I am talking from customer (and implementer) perspective: this information could save a lot of time, because currently I have to find such details myself during the interop testing.It is clear what vendors are worried that such info could be used as a tool in marketing games as Adrian already said, but it can be played in such way if only first implementations will be captured at the time of publication (like I am  king of the hill because I was first). Thus some other form (such as wiki lin IDR WG, as Ketan mentioned) should exist and updates about implementations can be put there. It might be easier than updating  RFCs while less formal.
 Anyway the transparent and honest mechanism to track down the status of implementations after publication is needed. Items 2 and 3 (reporting about MUSTs and optional details) will give enough information. 
The amount of information and details  (what is implemented exactly, i.e.  some TLVs now are from private range because IANA  did not allocate yet the numbers) for a customer are  more important  at the moment than waiting for all MUSTs will be implemented.
SY,Boris

    On Monday, August 22, 2022, 05:00:45 AM GMT+3, Chengli (Cheng Li) <c.l=40huawei.com@dmarc.ietf.org> wrote:  
 
 
Agree with Adrian and Robert, that is also my understanding of implementation status section in a draft.
 
  
 
Copy from Adrian’s first email.
 
  
 
- I support the idea of capturing the implementations status of the SPRING work during its development and at the time of publication request.
 
- I am strongly opposed to retaining that information in published RFCs.
 
- I support am neutral on idea of continuing to record implementation status after publication if there is WG consensus.
 
  
 
Thanks,
 
Cheng
 
  
 
  
 
From: spring [mailto:spring-bounces@ietf.org]On Behalf Of Robert Raszuk
Sent: Saturday, August 20, 2022 11:54 PM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: SPRING WG List <spring@ietf.org>
Subject: Re: [spring] Proposed policy on reporting implementation and interoperability
 
  
 
Hi Adrian,
 
  
 
I 100% agree with you. 
 
  
 
However what I understood as "Implementation Section" requirement was as simple a one paragraph including URL to an IETF wiki page. 
 
  
 
Not actual list of vendors and features supported. That would be highly inaccurate the moment it is posted.
 
  
 
Many thx,
 
Robert
 
  
 
On Sat, Aug 20, 2022 at 1:58 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
 

Hi Joel,
 
 
 
Thanks for bringing this to the WG for discussion.
 
 
 
As one of the authors of RFC 7942 I want to comment on the idea of including this “snapshot” status at the time of publication within the published RFC. I think this changes the purpose of collecting the information and making it public. It moves from being information that is valuable for assessing the status of the work, to something that verges on a marketing statement. In particular, companies that are able to get into the RFC reporting their implementations will, forever, be named in the RFC as known implementations, while other companies (perhaps those who waited for consensus before implementing) will be excluded. This seems wrong, and while the text you propose to include might make it clear that it is just a snapshot at the time of publication, it will still be there as a public record. The IETF is not a proxy marketing machine, and this information is not useful for the technical content of the RFC.
 
 
 
When we wrote 7942, we thought about this quite a lot. That led us to include:
 
   Authors are requested to add a note to the RFC Editor at the top of
 
   this section, advising the Editor to remove the entire section before
 
   publication, as well as the reference to RFC 7942.
 
But, at the same time, we described other places this information could be stored and updated, if that is what the working group wants to do.
 
Personally, I don’t think it is the IETF’s job to record implementation status after publication of an RFC, as this becomes very loaded and commercially sensitive. It could be hard to police, and could become contentious.
 
 
 
So, in summary:
 
- I support the idea of capturing the implementations status of the SPRING work during its development and at the time of publication request.
 
- I am strongly opposed to retaining that information in published RFCs.
 
- I support am neutral on idea of continuing to record implementation status after publication if there is WG consensus.
 
 
 
Thanks,
 
Adrian
 
 
 
From: spring <spring-bounces@ietf.org>On Behalf Of Joel Halpern
Sent: 03 August 2022 15:45
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
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring