I agree – it’s great to document the implementations but let’s not require every line of the drafts to implemented prior to publication.
Thanks, Acee From: spring <spring-boun...@ietf.org> on behalf of Tony Przygienda <tonysi...@gmail.com> Date: Friday, August 12, 2022 at 11:05 AM To: "Eric Vyncke (evyncke)" <evyncke=40cisco....@dmarc.ietf.org> Cc: John Scudder <j...@juniper.net>, "spring@ietf.org" <spring@ietf.org>, Alvaro Retana <aretana.i...@gmail.com>, Andrew Alston <andrew.als...@liquidtelecom.com> Subject: Re: [spring] Proposed policy on reporting implementation and interoperability On Thu, Aug 11, 2022 at 3:58 PM Eric Vyncke (evyncke) <evyncke=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: Bruno, Jim, Joel, Without any hat, or only with the experience of reviewing so many I-Ds from different areas and having implemented a couple of proof-of-concept implementations of various IETF drafts. The following are just comments for discussion, not criticisms because indeed running code is important at the IETF. RFC 7942, an IETF stream BCP (i.e., with IETF consensus), is already useful but *optional* while the proposal below would be mandatory. Hence, I share Dhruv’s question: will it also apply to experimental or informational documents or BCP? Joel, thank you for your reply to Dhruv, it seems a sensible solution. You may be aware of a long-standing project/idea/wish of the IESG to have a *living document concept* that could be updated for years after RFC publication. As you can imagine there are too many gears to make fast progress on this topic, but the current proposal is to move the ‘living’ part of the doc to a github repo under the IETF organization (e.g., done in MOPS). Wouldn’t it be a better fit than a section ‘carved in stone’ forever (even if time-stamped) in an RFC? Getting an implementation could sometimes be easy in Python or Go in Linux at a hackathon ;-), or in “slow path”, a little more complex in P4, even more in silicon... the ultimate step is of course a *deployment* outside of a virtualized lab:, i.e., in a production network. Of course, deployment (and interoperation) in a production network is the Graal ;-) But, where to put a useful but realistic needle *without delaying* the standardization process ? Getting things deployed is a monumentous task mostly, often deployment happens based on RFI/RFPs using RFCs (seldom based on drafts IME since those are moving targets). And normally, it's not RFCs being published as deployment documentation (though it happens, e.g. VxLAN). So, good potential for an unresolvable dependency circle if deployment documentation has any influence on RFC status. -- tony
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
