Joel & Spring chairs
I think this is a great idea and I support the proposal. As Ketan pointed out I think there should be consistency at least across all the routing area WGs related to normative language especially MUSTs in a specification. I don’t think we can say that 90% or even 99% of the MUSTs is Ok, and if there are MUSTs that could be downgraded to a SHOULD/MAYBE then the specification should have that changed. We should not have any wiggle room with MUSTs. For interoperability I think at each MUST statements should be implemented for an implementation to be able to claim to be 100% compliant with the specification. This is really important for operators to ensure interoperability with multi vendor environments. Kind Regards Gyan On Wed, Aug 3, 2022 at 10:45 AM Joel Halpern <j...@joelhalpern.com> wrote: > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
