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

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
specification.

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.

Best,
Robert

On Sat, Aug 13, 2022 at 1:04 AM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> 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 <jmh@joelhalpern.com>
> *Sent: *Wednesday, August 3, 2022 7:45 AM
> *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
>