I preface this message by remembering that the IETF is an organization of Individuals not Vendors. RJ Atkinson wrote: > The main bit of operator input that has been undertaken by IETF > has been NetConf (basically standardising an equivalent to the then > already deployed, albeit then proprietary, JunOS Script). That was > done because of the recommendation from the IAB Network Management > Workshop held in Reston earlier this decade (which itself was a bit > of IAB outreach, rather than IESG/IETF outreach). A bunch of people from many vendors reached out to the operator community, and that community consisted of several NANOGs, RIPE, LISA (!!), and others. We did not standardize JunOS Script, but what is largely speaking a series of transports and mechanisms above those transports. A model has been deferred. The effort was co-led by Andy Bierman and Simon Leinen. It was a broad attempt to provide an alternative to SNMP because configuration capabilities in SNMP have never been adopted. Bert went deliberately slowly so that we could try to work out what problems we really needed to address. The IAB workshop was part of that process, but I wasn't there nor was I in Bert's head so I can't say what effect it had. My recollection is that, Ran, you played a major positive role in this effort. Lots of heavy lifting. It is not a done deal. NETCONF's uptake remains limited. There are a lot of reasons for this. Perhaps things will improve, but perhaps we may need to revisit some of our decisions. We may not have gotten it right. All of this having been said, there was limited actual input from the operators, and what input we did receive (and I stood on the stage at NANOG to take input) was not well understood, and in some cases took to mean more than the operators intended. This happened in part because I and others muddled the questions to them at the time, but in part because operators (and perhaps even now) really did not care at the protocol level how we sent and received configuration information, so long as we had a way, and that way interoperated with tools like RANCID. What this tells me is that our engagement with operators either has to be deep and ongoing, or that it has to be well structured through clear questions that are well timed, with appropriate background given so that implications of the answers are well understood. In order to do the former, it means that not only do vendors need to go to NOGs, LISA, etc, but that operators need to get re-engaged in IETF. (It is a self fulfilling prophecy to simply call the IETF the IVTF and write it off. You don't fix things that way.) For the latter we need to work more closely with the leadership of customer organizations and user groups to take input. Even so, it's often difficult to take input from disparate groups and make everyone happy. Case and point: the calendaring standard of which I am now most acutely aware has small device vendors screaming at us due to its complexity, and yet valid usage cases that demand much of that complexity. We have to balance those use cases, with considerations such as whether Moore's Law (such as it is) will help mobile devices, or whether power limitations will keep footprints small. But user groups like members of Calconnect generally don't want to get to the nitty gritty of how to handle DST transitions in recurring events (although some individuals do go to that detail). Regards, Eliot _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf