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.i...@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 <j...@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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
