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-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> 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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
