Folks, I'm very much om the same page as Andy, having knowledge of implementations is a good thing. A "requirement" that we have an implementation before requesting that the document is published as an RFC is in most cases also good.
The tricky part is when to be flexible. I've asked for implementations for every intended PS we requested publication for. I have more than once been in a situation there operators tell me that the have the draft deployed, but where the vendor does not respond to questions about implementations. I've also seen where two vendors asked for early allocation because they are implementing and doing interop tests. Again one or both vendors does not respond to the implementation poll. One can speculate about the reasons for this, but it seems that often the decision whether or not to disclose an implementation is outside the mandate for people participating in immediate IETF process. In short, with a sufficient level of flexibility I support this. It would be good if we can have some type of report when some experience of the required implementation is at hand. /Loa On 2015-11-26 06:57, Andrew G. Malis wrote:
Based on my experience on both the vendor and operator side, I see some practical problems with this approach: - There are some (many?) operators that won’t put drafts into an RFP, only RFCs. - There are some (many?) vendors that won’t implement a draft or RFC, no matter how good the quality, unless they have a customer that wants the feature. That could be an existing customer that needs the feature operationally (which could lead to early implementation), or it could be a prospective customer with an RFP. - Vendors, of course, prioritize their implementation plans, and they usually put RFCs ahead of drafts, since drafts could change before publication, requiring a change in the implementation. For all these reasons, unless there’s an existing customer that needs a draft’s features to fix an operational problem, it’s less common for vendors to implement drafts than RFCs. A better approach might be to do an implementation poll just prior to WG LC (including implementation plans). The WG can then take the results of the poll into consideration during WG LC to see if there’s a consensus to send it to the IESG. There could be a draft that everyone agrees is really important to get published, but for whatever reason hasn’t yet been implemented. Cheers, Andy On Wed, Nov 25, 2015 at 5:19 PM, Martin Vigoureux <[email protected] <mailto:[email protected]>> wrote: Adrian, Thanks. Please see my reactions in-line. -m Le 25/11/2015 01:13, Adrian Farrel a écrit : Yeah, thanks Martin. The slide has... ==Raising the bar?== . Some documents are being pushed to IESG but without any implementation (plan) to support them . We are thinking of "requiring" that at least one implementation exists before handing the document to IESG . Thoughts? The first bullet allows for a plan to implement, the second requires implementation. The use of quotes in the second bullet suggests that you may be considering that the requirement may be flexible. Obviously we have an opening for discussion, but I wonder how you would decide when to be flexible. Good question :-) Indeed, the intent is to not be blindly strict. But defining the margins of flexibility is the tricky part then. I am pretty sure that this will be on a case by case with the default being the 1 implem requirement. I'll take an example: draft-ietf-bess-pta-flags It defines 2 registries as well as a new BGP Extended Community together with the associated processing procedures. The latter is definitely subject to being implemented and as such subject to the requirement we are discussing. However, what this document really does is to define a mechanism in support of specific needs. So I think that this could be a case where we could skip the 1 implem requirement (but apply it to the specs that use pta-flags). The minutes are a good indication of the level of support you received in the room, but not a deep discussion :-) There seems to be some confusion in the discussion between expediting (or unblocking) I-Ds that have an implementation, and delaying (or blocking) I-Ds that don't have implementations. While, in a world of limited resources, the two things are related, ideally we are not significantly gating the progress of one I-D because we are busy processing another. I'd say there are different points of view rather than confusion. In a situation where implementations are not considered mandatory, having one might indeed be a criteria for moving faster through the process but I think this is one amongst several possible other criterion. Now, I really, really support your motivation, viz. to reduce the pointless, unreviewed, unnecessary, or substandard drafts being sent for publication. The question is how to achieve that. The primary intent here is to send to IESG only documents that have an implementation. It makes their case stronger, is a contribution to reducing the load on IESG's shoulders, and also it anyway makes little sense to push through the standardization process an implementable specification but for which no implementation exists. The moment to submit to iesg is definitely a good time (and the last possible from a chair's perspective) to think about that. Now, your two sentences above open the door to a broader set of potential actions that could be taken to reach the objective, actions which are relevant during the I-D life cycle within the WG. But I guess this is a broader discussion. Adrian (still thinking about this) -----Original Message----- From: BESS [mailto:[email protected] <mailto:[email protected]>] On Behalf Of Martin Vigoureux Sent: 24 November 2015 23:17 To: [email protected] <mailto:[email protected]> Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls Hi Adrian, indeed, minutes should have been available sooner. situation has been corrected. The basic motivation for this is simply to avoid (over)loading the iesg with documents that have no (and could possibly never have an) implementation. Or, at least, if every spec gets implemented, it is to prioritize them. The discussion happened at the beginning of the meeting. It was on one of the slides I have presented as part of the WG status. -m Le 24/11/2015 17:07, Adrian Farrel a écrit : Hi Thomas, It's really hard to enter this discussion with any context. Could you post the minutes from the meeting and maybe summarise the points in favour of this approach? (Of course, I can listen to the audio when I have some spare time.) Thanks, Adrian _______________________________________________ BESS mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
