[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-farrel-rtg-manageability-requirements-00.txt



> > This is more than interesting -- it is fundamental to the
> > success of network management standardization in the IETF.
>
> I have to admit that while I see the potential value in this, I'm less
> enthusiastic about it. My main concern is how this will affect the role of the
> IETF and the level of frustration with it (which is already considerably high)
> in the routing industry. The problem is not with MIBs or configurable params,
> which we already do today, but with less tangible things like affect on network
> operations. The IETF doesn't operate the networks, so quite often the answer
> is--implement, deploy, get the bruises, come back and see what needs to be
> changed or tossed away. Of course, there are exceptions where the answer is
> obvious, but I don't think it's the rule..

Alex makes two valid points: that we must not over-burden the process of developing
protocols, and that we have not historically had the deployment experience by which to
judge "manageability".

To the first I would answer that of course we must not introduce requirements that
*unnecessarily* burden the process. However, if the additional process will make the end
result better at marginal cost, this cannot be a bad thing. I cite, for example, an
unwritten rule (at least I haven't seen it written) that options and alternatives are
"bad" because they increase the chance of interoperability and increase the management
overhead. Wouldn't it be nice to get the authors to flush this sort of thing out rather
than relying on the review process to catch it?

To the second point I answer that this is exactly my concern. That is, the answer
"implement, deploy, get the bruises" is one of the reasons why there is so much
frustration. We rally don't want to hear people saying "Didn't anyone think what effect
this would have on the network?", or "How on earth do you people expect us to manage this
feature in the real world?"

So, the proposal is not to develop detailed MIB modules or operational procedures as part
of each I-D. Rather, it is to get the authors to lift their heads a little and see what
direction they are facing. Are they making decisions now that will make management hard or
impossible in the future?

BTW, a comparison was made with the Security Considerations section currently mandated. It
is my experience that a high percentage of I-Ds collect comments on this section during
IESG review. These comments are not usually anything complex, but simply reflect the fact
that the WG and WG chairs have not insisted that a sensible security section is written
before the draft goes forward.

Adrian