Re: [spring] Proposed policy on reporting implementation and interoperability

[Tony Przygienda <[e-mail]>]

On Thu, Aug 11, 2022 at 3:58 PM Eric Vyncke (evyncke) <evyncke=
[e-mail]> 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