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]> 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]] On Behalf Of Martin Vigoureux >>> Sent: 24 November 2015 23:17 >>> To: [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] >>>> 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 >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
