I fully agree with Eric's points. In addition to the side-effects Eric had raised, I think it may intensify the monopolization in specification due to the implementation requirement before WG LC. For example, some giants could afford the implementation of whatever specifications they had proposed. However, for SMEs, they tend to start the implementation only when the specification has been standardized (e.g., RFC publishment).
Best regards, Xiaohu > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Eric C Rosen > Sent: Monday, November 30, 2015 11:33 PM > To: Martin Vigoureux; [email protected] > Cc: Benson Schliesser; Joel M. Halpern > Subject: Re: [bess] Introducing a one-implementation requirement before WG > last calls > > I am very strongly opposed to this "proposal". > > It takes the WG in the wrong direction, and attempts explicitly to undo the > work > that led to RFC4794, which eliminated some of the time-wasting requirements > that served only to further extend the already slow IETF process. > > The right time to preserve a specification in an archived form (such as an > RFC) is > when the specification has stabilized. Implementation and deployment > sometimes do not occur for years afterward, at which time the the original > authors and/or editors of the specification might have moved on to other > pursuits. In WGs that do have implementation requirements, specification that > were implemented years ago often sit around as internet-drafts for extended > periods of time, just because no one is available to restart the > standardization > process. Often the drafts expire, and sometimes remain expired for years after > they've been deployed. This creates considerable confusion about whether the > drafts have been abandoned. > > There is also the point that Andy has raised, that delaying publication may > also > delay deployment. > > I believe it is improper for the IETF to be demanding details about > implementations, release cycles, and release dates. It should be noted that > it > becomes quite difficult to gather this sort of information about a draft that > has > been sitting around for years, especially if that draft has has been > implemented > and deployed piecemeal. > > There are also some process issues to discuss. > > > [Martin] the point of our e-mail is to continue the discussion on the > > list. We explicitly say that this is a proposal and that we are open > > to comments. > > The email in question certainly suggests that the WG chairs have already made > a > decision to impose a new requirement, but are allowing two weeks (during what > is a holiday season for many) for "discussion" before they announce that > there is > a consensus in favor of their proposal. This does not seem like an > appropriate > approach, and imho would be worthy of appeal. > > The routing area used to have more implementation requirements, but after > extensive discussion in 2006 (discussion lasting more than two weeks), these > requirements were eliminated by RFC4794. The reason is clear enough. > Quoting RFC4794: > > "Today, one of the big problems the IETF faces is timeliness. > Applying additional rules to a certain class of protocols hurts the > IETF's ability to publish specifications in a timely manner." > > I don't think anything has changed since the topic was discussed in 2006. We > should be looking for ways to speed up the process, not looking for even more > ways to slow it down. > > > [Adrian] To be clear, the WG is allowed to make a decision to do this. > > http://datatracker.ietf.org/doc/rfc4794/ > > Are you referring to the following paragraph: > > Some working groups within the Routing Area have developed > procedures, based on RFC 1264, to require implementations before > forwarding a document to the IESG. This action does not prevent > those working groups from continuing with these procedures if the > working group prefers to work this way. We encourage working groups > to put measures in place to improve the quality of their output. > > I don't see that this gives individual WGs (not to mention WG chairs) any > right to > impose arbitrary new rules. It only allows them to keep existing rules. The > most it says about allowing the creation of new rules is: > > that does not prohibit the Routing Area Directors from requiring > implementation and/or operational experience > > though this presumably would also be subject to appeal if it were applied > arbitrarily. > > > [Martin] 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. > > I don't think the problem of AD workload can be addressed by having a single > WG add more delay to its process. Certainly I don't agree that the IESG > workload problem should be addressed by having the IETF do less work. > > > > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
