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

Re: EOS WG Status



>Q1:
>   Is the EOS work expected and/or permitted to extend the syntax of a PDU?
>   I.e. are we free to introduce new types (analogous to Counter64 in the
>   v1->v2 transition), or is this work concentrating on simply extending the
>   semantics of the current basic structure (analogous to GetBulk in v1->v2)

IMHO, I would only extend the protocol if there was no better way to
accomplish and end.  as you know, extending the protocol is a serious
thing.  agent code needs to be re-rev'd; nms code, the same.  not to
mention all the retesting and requalification (each company will have
to allocate sqa testing time) and the cost of updating docs, 3rd party
sniffer code <g>, etc.  that's a LOT of things on both sides of the
wire (and admin style things not on the wire).  there is a non-trivial
cost associated with all this.  my point is that if there is a less
invasive way of accomplishing a given goal, changing the actual
protocol should be the last possible action taken.

bringing this to a concrete example (that of bulk-data retrieval, of
which I have a mib submission), I found that by leveraging existing
protocols (scp, ftp, tftp, etc) and existing compression (gzip, bzip,
etc), that no new PDU types were needed in order to accomplish the end
goal.  zero code on the NMS has to be rev'd.  this is A Good Thing and
helps control cost of deployment as well as reduce time to market and
possible bug count.  yeah, real world issues..

if I believed that extending the PDUs/protocol really was the _only_
way to accomplish this goal, then fine, lets do it.  but I would
highly prefer to find a hybrid or 'more gentle' solution before going
to that other extreme.  at least _attempt_ to find a method that will
work within the current system before upping the anty in protocol/pdu
versions.


cheers,

-- 
bryan