> Robert, why would we discard information? I view support of all normative MUSTs as something necessary to claim (full or partial) support of a given draft.
No support of even a single MUST makes an implementation not something which should be part of a given spec. Discard was about the comment made that this section should be part of the very draft in question. It is of course useful to write a new draft or wiki table to document it - no objections here. Many thx On Sat, Aug 13, 2022 at 8:02 PM Joel Halpern <j...@joelhalpern.com> wrote: > Robert, why would we discard information? It seems that if folks do > report such partial compliance, it is helpful to include it. Whether > anyone will make such a report remains to be seen. > > Yours, > > Joel > On 8/13/2022 1:56 PM, Robert Raszuk wrote: > > 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
