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

The proposal is to document what we can determine.  It is NOT to block 
publication until it is all implemented.

Yours,

Joel

On 8/12/2022 5:40 PM, Acee Lindem (acee) wrote:
>
> 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-bounces@ietf.org> on behalf of Tony Przygienda 
> <tonysietf@gmail.com>
> *Date: *Friday, August 12, 2022 at 11:05 AM
> *To: *"Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>
> *Cc: *John Scudder <jgs@juniper.net>, "spring@ietf.org" 
> <spring@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, Andrew 
> Alston <Andrew.Alston@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.com@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