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 <mailto:j...@joelhalpern.com>
*Sent: *Wednesday, August 3, 2022 7:45 AM
*To: *SPRING WG List <mailto: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
