> On 22 Dec 2015, at 16:22, Nadeau Thomas <[email protected]> wrote: > > > The action I am trying to tease out of this thread is how do we take > action > going forward? There are many who are saying (and doing) what you say below; > however,
This should IMO be OK. One thing that might help avoid unnecessary duplication of work is to keep and up-to-date directory, where everybody could register their modules. Everything else could be a bottom-up process. Lada > there are related discussions on the RFC6020 update to the module update rules > claiming that we should only focus on IETF-realted modules. Do you see the > catch-22 > I am trying to make clear here? The other issue is the simple process for > those modules > that are developed here. Should we move them all to an external model, should > we > amend the IETF’s processes to accommodate rapid model development and > iteration? > > —Tom > > >> On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka <[email protected]> wrote: >> >> >>> On 22 Dec 2015, at 14:06, Nadeau Thomas <[email protected]> wrote: >>> >>> >>> [moving the thread to its own discussion.] >>> >>>> This is a blocking factor that people are not considering: The RFC >>>> process the >>>> IETF has in place is not suitable for rapid/modern/canonical model >>>> development. It will >>>> be difficult for the IESG review process to scale to even a couple models >>>> during any given >>>> telechat period given the state of the document review/approval process. >>>> How do we >>>> envision the IESG reviewing 250+ models (and growing)? Besides the >>>> initial RFC version, >>>> rapid refresh/update of models has the same issues. >>> >>> I don't disagree, but I propose that we stick to the oper state discussion >>> in this email thread. >> >> I agree with Tom. I personally decided not to work on any new module in the >> IETF any time soon. I am currently working on a number of modules related to >> DNS, they will be freely available for review and use by everybody, but I >> don't want to go through a similar process as with ietf-routing, and then be >> stymied by the update rules. >> >> Lada >> >>> >>> Regards, Benoit >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
