ietf
[Top] [All Lists]

Re: NAT+PT for IPv6 Transition & Operator Feedback generally

2007-11-15 07:37:47
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf